Message74751
| Author |
fredrikj |
| Recipients |
fredrikj, loewis, mark.dickinson, rhettinger, terry.reedy, vstinner |
| Date |
2008年10月14日.15:38:18 |
| SpamBayes Score |
1.8379724e-09 |
| Marked as misclassified |
No |
| Message-id |
<1223998701.12.0.758807199355.issue3439@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> One other note: in Fredrik's patch there's commented out code for a
> numbits *property* (rather than a method). Is there any good reason to
> make this a property?
Aesthetically, I think numbits as a function would make more sense.
(Maybe if the hypothetical imath module comes along...)
> Since numbits() cost is O(n) with n: number of digits. I prefer a
> method than a property because, IMHO, reading a property should be
> O(1) (*read* an attribute is different than *compute* a value).
Unless I missed something, numbits() is O(1). Only the topmost word in a
number needs to be examined.
> reading a property should be O(1) (*read* an attribute is different
> than *compute* a value).
O(1) is necessary but not sufficient. My sense is that an attribute
should access an existing "part" of an object while an operation that
involves creating a "new" object should be a method. Compare
complex.real/.imag and complex.conjugate(). |
|