On 4/4/06, Barry Warsaw <[EMAIL PROTECTED]> wrote: > Just a data point. In our API, we've been converting all of our no-arg > methods to attributes/properties, each of which may or may not be > writable of course. It's simplified our Python code enormously, and > made it much more readable. Certainly "foo.get_something()" and > "foo.set_something(thing)" are much better spelled "foo.something" and > "foo.something = thing".
Right. It sounds like your original API was using Java-style getters and setters too much, and then converting to Python-style attributes and properties is an obvious improvement. > As a general principle, we've been making this conversion for any > getters and setters that take no arguments, both for pure-Python types > and C-implemented types. While we were at it, we changed everything > that returns a newly formed concrete sequence to returning an iterator > (which broke code that was doing random access into the sequence, but > that's another story). Let me ask a clarification here. Do you now have properties that return new iterators? That seems a bad idea, for the following reason: I'd expect these two code sequences to have the same effect: a = obj.foo b = obj.foo and a = b = obj.foo If obj.foo were to be a property returning a new iterator on each access, the first example would end up with a and b separate (independent) iterators, while the second example would make a and b aliases for the same iterator. I hope I misunderstood you; something that returns an iterator should definitely not be a property but a real method. > I don't know whether Python 3000 wants to encourage that style, but it > works well for us. I certainly want to continue discouraging setter and getter methods where plain attributes would do. The question is where to draw the line. I don't believe you really meant "all no-args methods". Perhaps you meant "all side-effect free argument-less methods that return the same value each time (or at least until some explicit change to the object is made) and that can be computed reasonably cheap"? The __hash__() method qualifies, which is why it's a tough call (I'll come back on that; I want to come up with a reason why __hash__() should remain a method). The iterator-getting example above doesn't qualify. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
