Re: [Python-Dev] Declaring setters with getters
"Steven Bethard" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > 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 > It *can* be written as Fred suggested: see http://groups.google.co.uk/group/comp.lang.python/browse_thread/thread/b442d08c9a019a8/8a381be5edc26340 However that depends on hacking the stack frames, so the implementation probably isn't appropriate here. ___ Python-Dev mailing list [email protected] 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: > 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. I was expecting this would be brought up, but that just ain't gonna happen. If you don't repeat the name, the decorator has to root around in the surrounding scope, which is fraught with peril. Solutions based on sys._getframe() have been around for years (e.g. several the Cookbook recipes) and if I had approved of that technique I would have adopted one long ago. However I don't approve of it. It has always been and will always continue to be my position that these are semantically unkosher, because it means that you can't wrap them in convenience functions or invoke them in different contexts, and that means that the semantics are hard to explain. If you really want another argument, repeating the property name actually does have an additional use case: you can have a read-only property with a corresponding read-write property whose name differs. E.g. class C(object): @property def encoding(self): return ... @propset(encoding) def encoding_rw(self, value): ... c = C() c.encoding = "ascii" # Fails c.encoding_rw = "ascii" # Works I've seen people do this in the filesystem: a read-only version that may be cached or replicated, and a separate writable version. Reading the writable version works too, of course. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 Nov 1, 2007, at 10:01 AM, Guido van Rossum wrote: > On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> 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. > > I was expecting this would be brought up, but that just ain't gonna > happen. If you don't repeat the name, the decorator has to root around > in the surrounding scope, which is fraught with peril. Solutions based > on sys._getframe() have been around for years (e.g. several the > Cookbook recipes) and if I had approved of that technique I would have > adopted one long ago. It's also not as if you're writing some string value the second time, so any typos in the name will be caught early on. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRyoLjnEjvBPtnXfVAQKcHAQAt8cmfJa93nVMX4/cIUTzUvke2LMhiKbj 5auo/TlymK6GMrKCLSpIOVfxMboj0tf5RqL8oS72OS6w6K+jlBiVFRZPf0NQtO1s WXsKDR/tw5B8iiTsoi8CRASsbEBetTrHIa5WqWqYbNk1sE7GNGTK4kIGoMd1txyp IdhLvYSJK7Q= =v4I7 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] 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 02:01 pm, [EMAIL PROTECTED] wrote: On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: As long as we're all tossing out ideas here, my 2�. I vastly prefer this: >>@property.set to this: > @property.set(attribute) I don't approve of it. It has always been and will always continue to be my position that these are semantically unkosher, because it means that you can't wrap them in convenience functions or invoke them in different contexts, and that means that the semantics are hard to explain. Point taken. If you really want another argument, repeating the property name actually does have an additional use case: you can have a read-only property with a corresponding read-write property whose name differs. I don't actually have this use-case, but it does make the actual semantics of the provided argument a bit clearer to me. It's not an implementation detail of fusing the properties together, it's just saying which property to get the read accessor from. This is a minor nit, as with all decorators that take an argument, it seems like it sets up a hard-to-debug error condition if you were to accidentally forget it: @property def foo(): ... @property.set def foo(): ... would leave you with 'foo' pointing at something that wasn't a descriptor at all. Is there a way to make that more debuggable? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Request for inclusion in 2.5.2 (5-for-1)
Issue http://bugs.python.org/issue1663329 details an annoyance in the subprocess module that has affected several users, including me. Essentially, closing hundreds of thousands of file descriptors by round-tripping through the python exception machinery is very slow, taking hundreds of milliseconds and at times many seconds. The proposed fix is to write this loop in c. The c function is but a handful of lines long. I purposefully kept the implementation trivial so that it will work on all unix variants (there is another issue that contains a super-duper optimization for AIX, and other possibilities exist for Solaris, but the simple fix yields a ten-fold speedup everywhere but windows, so I didn't think that it was worth the complexity). Though technically relating only to performance, I consider this a bug-fix candidate as mysterious multi-second delays when launching a subprocess end up making the functionality of close_fds unusable on some platform configurations (namely, those with high MAX_FD set). It would be great to see this is 2.5.2. Understanding that issue evaluation takes significant effort, I've done some evaluation/triage on other open tickets: See issues for detailed comments. http://bugs.python.org/issue1516330: No clear problem, invalid patch. Recommend rejection. http://bugs.python.org/issue1516327: No clear problem, no patch. Recommend closing. http://bugs.python.org/issue1705170: reproduced. Conjecture as to why it is occurring, but I don't know the guts well enough to propose a decent fix. http://bugs.python.org/issue1773632: tested patch. Recommend accepting unless there are things I don't know about this mysterious _xmlrpclib extension (which there doubtlessly are) http://bugs.python.org/issue738948: Rather old PEP that has gathered no comments. Calling it a "PEP" is generous--it is really just a link to an academic paper with a note about how this might be integrated into Stackless. Thanks, -Mike ___ Python-Dev mailing list [email protected] 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 11/1/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > This is a minor nit, as with all decorators that take an argument, it > seems like it sets up a hard-to-debug error condition if you were to > accidentally forget it: > > @property > def foo(): ... > @property.set > def foo(): ... > > would leave you with 'foo' pointing at something that wasn't a > descriptor at all. Is there a way to make that more debuggable? Yes, if you remember my initial post, it contained this line: assert isinstance(prop, property) And even without that, accessing prop.fget would fail immediately; so instead of a non-functioning property, you get an exception at class definition time. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Explicit frame ref? (was Re: Declaring setters with getters)
At 07:01 AM 11/1/2007 -0700, Guido van Rossum wrote: >However I don't approve of it. It has always been and will always >continue to be my position that these are semantically unkosher, >because it means that you can't wrap them in convenience functions or >invoke them in different contexts, and that means that the semantics >are hard to explain. This is semi-random tangent, but what if there was a way to explicitly refer to the current frame as a function argument? Then, the implicitness that creates these problems becomes explicit, instead. As it happens, I write virtually all my frame-oriented decorators to take a 'frame' argument anyway, and only guess when it's not supplied. So, having a convenient way to pass the argument would be the only thing needed. Unfortunately, to be really useful, the name or symbol used would have to be more compact than the name or other data that you planned to get from the frame in the first place. "sys._getframe()" itself, for example, is way too long of a string. Even shortening this to something like 'here()' still seems too inconvenient, but to go any less than that invites the use of line-noise for syntax. Oh well, it was worth a try. ___ Python-Dev mailing list [email protected] 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/25/07 - 11/01/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. 1314 open (+21) / 11538 closed (+22) / 12852 total (+43) Open issues with patches: 415 Average duration of open issues: 683 days. Median duration of open issues: 773 days. Open Issues Breakdown open 1310 (+21) pending 4 ( +0) Issues Created Or Reopened (43) ___ 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 http://bugs.python.org/issue1342created tiran XMLGenerator: nice elements 10/27/07 http://bugs.python.org/issue1343created panzi subprocess.communication doc could use clarification 10/27/07 http://bugs.python.org/issue1344created dsturtevant Fix for test_netrc on Windows10/27/07 http://bugs.python.org/issue1345created tiran patch Error using >>> from OpenGL.GLUT import *10/27/07 CLOSED
[Python-Dev] None in arguments to "".find and family of functions
Hello people!
I'm following the issue 1259 (http://bugs.python.org/issue1259)
It basically says that this should be ok: "'asd'.find('s', None,
None)", as the documentation says that "start" and "end" arguments
behaves like in slices (right now it gives a TypeError).
I created a patch, that solves the problem presented in that patch, as
is suggested by Barry A. Warsaw.
The patch touches three files:
- Lib/test/string_tests.py: The test cases for this.
- Objects/stringobject.c: Here I modified the string_find_internal()
function, for PyArg_ParseTuple to not call directly to
PyEval_SliceIndex: I just call it if the function received an argument
and is not None.
- Objects/unicodeobject.c: Here I needed to make the same in
unicode_find(), unicode_rfind(), unicode_index(), and
unicode_rindex(), so I created another function called
_ParseTupleFinds(), for this family of functions, which handles the
arguments and returns the needed info for each function.
All the tests pass ok, I'm sending this mail to see if anybody could
please review the patch before I apply it, as this is the first patch
that I create in C. Feel free to ignore this mail if the patch is ok,
:)
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
___
Python-Dev mailing list
[email protected]
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 Nov 1, 2007, at 10:26 AM, [EMAIL PROTECTED] wrote: > This is a minor nit, as with all decorators that take an argument, > it seems like it sets up a hard-to-debug error condition if you were > to accidentally forget it: > > @property > def foo(): ... > @property.set > def foo(): ... > > would leave you with 'foo' pointing at something that wasn't a > descriptor at all. Is there a way to make that more debuggable? How about this: give the property instance a method that changes a property from read-only to read-write. No parens, no frame magic. As a small bonus, the setter function would not have to be named the same as the property. class A(object): @property def foo(self): return 1 @foo.setter def set_foo(self, value): print 'set:', value -Tony ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python tickets summary
2007/10/25, Ron Adam <[EMAIL PROTECTED]>: > Clicking on one of the filter links changes the title back. (No Keyword, > Patch, P3K) Fixed, this was a bug, :( > I think the keyword and keywords interface can be improved. Do you have > any plans in that direction? Surely! But, no, I have no plans to do it, as I can not make cgi scripts in my hosting, so these pages are statics, generated every night, and that's all... > How do you get the data the page is built from? Parsing the results of http://bugs.python.org/ Regards, -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] 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
-1. Looks like more magic, not less, to me. On 11/1/07, Tony Lownds <[EMAIL PROTECTED]> wrote: > > On Nov 1, 2007, at 10:26 AM, [EMAIL PROTECTED] wrote: > > This is a minor nit, as with all decorators that take an argument, > > it seems like it sets up a hard-to-debug error condition if you were > > to accidentally forget it: > > > > @property > > def foo(): ... > > @property.set > > def foo(): ... > > > > would leave you with 'foo' pointing at something that wasn't a > > descriptor at all. Is there a way to make that more debuggable? > > How about this: give the property instance a method that changes a > property from read-only to read-write. > No parens, no frame magic. As a small bonus, the setter function would > not have to be named the same as the > property. > > class A(object): >@property >def foo(self): > return 1 > >@foo.setter >def set_foo(self, value): > print 'set:', value > > -Tony > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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: > if you want more control, you can just get the property object out of > the class you want You're quite right. I was thinking that getting the property would trigger the access machinery, but of course you're getting it from the class rather than the instance, so that doesn't happen. -- Greg ___ Python-Dev mailing list [email protected] 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
Fred Drake wrote: >@property >def attribute(self): >return 42 > >@property.set >def attribute(self, value): >self._ignored = value Hmmm... if you were allowed general lvalues as the target of a def, you could write that as def attribute.set(self, value): ... -- Greg ___ Python-Dev mailing list [email protected] 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 wrote: > Let's stick with "propset" which has precedent as an svn action and > serves as a short, simple mnemonic to the functionality. But if we're going to have "propset", it raises the question of why there isn't a "propget". -- Greg ___ Python-Dev mailing list [email protected] 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:11 AM 11/2/2007 +1300, Greg Ewing wrote: >Raymond Hettinger wrote: > > Let's stick with "propset" which has precedent as an svn action and > > serves as a short, simple mnemonic to the functionality. > >But if we're going to have "propset", it raises the question >of why there isn't a "propget". Which can be eliminated by having property.setter, especially in the form: @property def foo(self): ... @foo.setter def foo(self, value): ... @foo.deleter def foo(self): ... This even preserves Guido's "read-only + read-write" use case, and saves us a builtin. ___ Python-Dev mailing list [email protected] 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 11/1/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:11 AM 11/2/2007 +1300, Greg Ewing wrote: > >Raymond Hettinger wrote: > > > Let's stick with "propset" which has precedent as an svn action and > > > serves as a short, simple mnemonic to the functionality. > > > >But if we're going to have "propset", it raises the question > >of why there isn't a "propget". > > Which can be eliminated by having property.setter, especially in the form: > > @property > def foo(self): > ... > > @foo.setter > def foo(self, value): > ... > > @foo.deleter > def foo(self): > ... > > This even preserves Guido's "read-only + read-write" use case, and > saves us a builtin. Although it begs the question what happened to @foo.getter. I'm only +0 on this -- I can't quite pinpoint what's wrong with it but it doesn't fell 100% right. Maybe I just need to sleep on it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 10:23 PM, Barry Warsaw wrote: > BTW, +1 on this. I like Fred's suggestion of property.set(). Thanks! Of all the proposals that have been presented, I still like that the best. Guido's use case of wanting to give the r/w property a different name than the r/o property is a good one, though I've not run across it myself. I'd be satisfied with passing in the origin property, though I'd want to be able to do that for the get method as well as the set and delete methods. That would better support being able to extend a property in a derived class. For example: class Base(object): @property def attribute(self): return 42 class Derived(Base): @property.get(Base.__dict__["attribute"]) def attribute(self): self.do_something() return super(Derived, self).attribute What I don't like is the difficulty of getting the raw descriptor from the base class. It would be good to be able to say: class Derived(Base): @property.get(Base.attribute) def attribute(self): self.do_something() return super(Derived, self).attribute I doubt that's all that hard to achieve, at least for a known property type. To support descriptors of completely different types, the syntax from the first example may be required unless some other crutch is added. -Fred -- Fred Drake ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Does Python need a file locking module (slightly higher level)?
> The API and almost all test cases are defined in a _FileLock base > class. You could (in theory at least) subclass it to provide locking > through some other shared resource like a database and not have to > write and or many other test cases. Okay, this is up on my website: http://www.webfast.com/~skip/python/ It took me a little longer to implement than I thought because I decided to implement an SQLite-based _FileLock subclass, mostly as a proof-of-concept. I'm still waiting for the name "lockfile" to free up in PyPI to put it there. Skip ___ Python-Dev mailing list [email protected] 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 Nov 1, 2007, at 9:18 PM, Fred Drake wrote:
Thanks! Of all the proposals that have been presented, I still like
that the best.
I've attached a quick hack of an implementation, just to play with it
and see how it feels. Here's an example use:
from property import property
class Base(object):
@property
def attribute(self):
print("Base.attribute (getter)")
return 42
@property.get(attribute)
def rwattribute(self):
print("Base.rwattribute (getter)")
return self.attribute * 2
@property.set(rwattribute)
def rwattribute(self, value):
print("Base.rwattribute (setter)")
self.saved = value
class Derived(Base):
@property.get(Base.attribute)
def roattribute(self):
print("Derived.roattribute (getter)")
return self.attribute / 2
-Fred
--
Fred Drake
import __builtin__
class property(__builtin__.property):
__slots__ = ()
@classmethod
def get(cls, base):
return PropertyCombiner(cls, base).get
@classmethod
def set(cls, base):
return PropertyCombiner(cls, base).set
@classmethod
def delete(cls, base):
return PropertyCombiner(cls, base).delete
class PropertyCombiner(object):
__slots__ = "cls", "base"
def __init__(self, cls, base):
assert isinstance(base, __builtin__.property)
assert issubclass(cls, property)
self.cls = cls
self.base = base
def get(self, fget):
return self.cls(fget, self.base.fset, self.base.fdel)
def set(self, fset):
return self.cls(self.base.fget, fset, self.base.fdel)
def delete(self, fdel):
return self.cls(self.base.fget, self.base.fset, fdel)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
