From: Ian B. <ia...@co...> - 2001-11-01 18:38:46
|
I don't know who all noticed it, but Python 2.2 seems to add a feature to make individual attribute accesses fully dynamic -- i.e., with a getter, setter, and deleter. This potentially alleviates the need for the *() and set*() functions that are all over the place -- and without fancy/annoying __getattr__ magic. http://www.amk.ca/python/2.2/index.html#SECTION000340000000000000000 Ian |
From: <ir...@ms...> - 2001-11-01 20:51:51
|
On Thu, Nov 01, 2001 at 12:40:27PM -0600, Ian Bicking wrote: > I don't know who all noticed it, but Python 2.2 seems to add a feature > to make individual attribute accesses fully dynamic -- i.e., with a > getter, setter, and deleter. This potentially alleviates the need for > the *() and set*() functions that are all over the place -- and > without fancy/annoying __getattr__ magic. > > http://www.amk.ca/python/2.2/index.html#SECTION000340000000000000000 They are definitely very intriguing. I think they're getting off to a slow start because they've been underdocumented. Guido's 2.2 document (or maybe it was this one) only described them by example without the explanation--making you think they're good for *something*, but you're not quite sure what. As ppl talk more about where they can be useful, ppl will have a better feel for it. Also, the interface changed on this. There was a "getset" function for a while that seems to have disappeared, and ppl were waiting to see whether this property interface was here to stay. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Chuck E. <Chu...@ya...> - 2001-11-01 21:45:37
|
At 12:55 PM 11/1/2001 -0800, Mike Orr wrote: >On Thu, Nov 01, 2001 at 12:40:27PM -0600, Ian Bicking wrote: > > I don't know who all noticed it, but Python 2.2 seems to add a feature > > to make individual attribute accesses fully dynamic -- i.e., with a > > getter, setter, and deleter. This potentially alleviates the need for > > the *() and set*() functions that are all over the place -- and > > without fancy/annoying __getattr__ magic. > > > > http://www.amk.ca/python/2.2/index.html#SECTION000340000000000000000 > >They are definitely very intriguing. I think they're getting off >to a slow start because they've been underdocumented. Guido's 2.2 >document (or maybe it was this one) only described them by example >without the explanation--making you think they're good for *something*, >but you're not quite sure what. As ppl talk more about where they can >be useful, ppl will have a better feel for it. > >Also, the interface changed on this. There was a "getset" function for >a while that seems to have disappeared, and ppl were waiting to see >whether this property interface was here to stay. Yes, the interface did change and I wasn't even aware of it until now! I'd still like to see it rolled into the def part as in "defget" and "defset" or even "get" and "set" in place of "def". This would make it feel more like a part of the language and be a bit smoother. Nonetheless, the 2 versions I have seen so far are a big improvement over the __getattr__ hook and the ugliness that came with it. I've been having the same thoughts as Ian--that once this feature settles down and provided that it is convenient and stable--we could move from: print self.foo() self.setFoo(1) self._foo = value to: print self.foo self.foo = 1 self.foo = value I think the result is: * Much more convenient for writing and reading * Much more Pythonic We would need a script to convert existing Webware projects to the fullest extent possible. But finally, I haven't brought this up before because this feature really needs to stabilize and get hammered on in Python 2.2 for a while before we can embrace it. -Chuck |
From: Ian B. <ia...@co...> - 2001-11-01 21:51:15
|
Chuck Esterbrook <Chu...@ya...> wrote: > we could move from: > print self.foo() > self.setFoo(1) > self._foo = value > > to: > print self.foo > self.foo = 1 > self.foo = value > > I think the result is: > * Much more convenient for writing and reading > * Much more Pythonic The other advantage is that it allows more powerful subclassing, since right now classes are usually using the concrete values instead of the proper setters and getters. Ian |
From: <ir...@ms...> - 2001-11-01 22:07:53
|
On Thu, Nov 01, 2001 at 01:45:28PM -0800, Chuck Esterbrook wrote: > >> http://www.amk.ca/python/2.2/index.html#SECTION000340000000000000000 > > > >Also, the interface changed on this. There was a "getset" function for > >a while that seems to have disappeared, I'm glad "getset" is gone. It implied it was a set constructor or extractor but it wasn't. (Still hoping Python gets sets someday, pardon the pun. You can mimic them with dictionaries, but that's like driving a car across the street to get the mail.) -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Chuck E. <Chu...@ya...> - 2001-11-01 23:25:32
|
At 02:12 PM 11/1/2001 -0800, Mike Orr wrote: >(Still hoping Python gets sets someday, pardon the pun. You can mimic >them with dictionaries, but that's like driving a car across the street >to get the mail.) I agree. It would also fit better with what MiddleKit is currently calling a "list" but for which it doesn't really guarantee an order. I think list, set and map are the 3 Big Containers that every language should have. -Chuck |
From: Ian B. <ia...@co...> - 2001-11-01 23:38:04
|
Chuck Esterbrook <Chu...@ya...> wrote: > >(Still hoping Python gets sets someday, pardon the pun. You can mimic > >them with dictionaries, but that's like driving a car across the street > >to get the mail.) > > I agree. It would also fit better with what MiddleKit is currently calling > a "list" but for which it doesn't really guarantee an order. > > I think list, set and map are the 3 Big Containers that every language > should have. I think dictionaries make for pretty decent sets. Just like lists make for decent stacks and queues (well, once we got the thread-safe .pop()). Ian |
From: Chuck E. <Chu...@ya...> - 2001-11-01 23:50:35
|
At 05:40 PM 11/1/2001 -0600, Ian Bicking wrote: >I think dictionaries make for pretty decent sets. Just like lists >make for decent stacks and queues (well, once we got the thread-safe >.pop()). In MiddleKit if you were to specify the type of an attribute as a dictionary, you would immediately wonder what the key is. But in the case of using the dictionary of set, the key no longer has the same meaninging the value is nonsense. A set is non-ordered collection. A dictionary is map from keys to values. Being able to simulate one with the other, doesn't make it natural to work with or easy to understand. -Chuck |
From: <ir...@ms...> - 2001-11-01 23:57:41
|
On Thu, Nov 01, 2001 at 05:40:31PM -0600, Ian Bicking wrote: > Chuck Esterbrook <Chu...@ya...> wrote: > > >(Still hoping Python gets sets someday, pardon the pun. You can mimic > > >them with dictionaries, but that's like driving a car across the street > > >to get the mail.) > > > > I agree. It would also fit better with what MiddleKit is currently calling > > a "list" but for which it doesn't really guarantee an order. > > > > I think list, set and map are the 3 Big Containers that every language > > should have. > > I think dictionaries make for pretty decent sets. Just like lists > make for decent stacks and queues (well, once we got the thread-safe > .pop()). Lists work very well for stacks or queues, and the other features of lists (random access) don't get in the way. But with dictionaries-as-sets, every time you add a key you have to make up a bogus value. None is the most obvious choice, but that evaluates to false so it's a little misleading. On the other hand, 1 is suitably true, but it's even more misleading. Less of a problem is having to do mySet.has_key(Thing) instead of "Thing in mySet", although I guess maybe you can do that in Python 2.2. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@ji...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |