On Sep 29, 2:34 am, Carl Banks <[EMAIL PROTECTED]> wrote: > On Sep 29, 1:44 am, George Sakkis <[EMAIL PROTECTED]> wrote: > > > > > On Sep 29, 12:08 am, Terry Reedy <[EMAIL PROTECTED]> wrote: > > > > George Sakkis wrote: > > > > On Sep 28, 2:29 pm, process <[EMAIL PROTECTED]> wrote: > > > > >> I have heard some criticism about Python, that it is not fully object- > > > >> oriented. > > > > > That's not a bug, it's a feature ;-) > > > > >> Why isn't len implemented as a str.len and list.len method instead of > > > >> a len(list) function? > > > > > As Terry Reedy wrote, partly history and partly practicality. There's > > > > no philosophical reason why we write "len(x)" (generic builtin), > > > > "x.append(1)" (method) or "del x[i]" (statement). The latter in > > > > particular is IMHO a design wart; there's no reason for not writing it > > > > as "x.delete(i)". > > > > As a general rule and matter of practice, methods that apply to all or > > > most classes (or all number classes) have built-in functions that call > > > the corresponding special method (or C-level slot). > > > It would be easier to justify this rule if it was more clear-cut, and > > specifically if it was applied only to methods that are available to > > *all* classes (such as type() and getattr()) rather than the ill- > > defined "most classes". > > That wasn't your original claim, though. You claimed there was no > philosophical reason, then Terry gave you one, then you said, well > there's no clear cut reason. Unless you define "philosophical" as > "clear cut" (a definition I'm not sure many would agree with).
I won't argue about that, just s/philosophical/clear cut/ then. > Anyway, you are right to claim there's no clear cut distinction, just > as there's never any clear cut distinction over whether something > should be an operator or not. Addition is only available to the ill- > defined "most classes", yet not only is it not a method, it has its > own syntax. There's no clear cut distinction there, it's just a > design decision. > > Likewise, making len() into a function is just a > design decision, that len is a common enough operation that it need > elevated status. It's really nothing more. Python wouldn't suffer > much regardless if len is a method, a built-in function, or an > operator with its own syntax. I'm not quite sure it's exactly the same. The distinction between operators and non-operators is syntactically clear cut: operators consist of punctuation characters and (binary operators) use infix syntax. Yes, from a pure semantics standpoint this distinction is redundant; a language could support a method-only syntax, but there is much value in using terse intuitive symbols for certain domains (with math being the prominent one). For example I would be much less opposed to len() being defined as, say, |x| if "|...|" was a valid operator. I don't see the same value in creating a distinction between methods and builtin functions unless the latter are truly generic (and even then I wouldn't mind having them as methods of the base object class, e.g. object.type()). Having a builtin len(x) delegate to x.__len__() seems harder to justify. George -- http://mail.python.org/mailman/listinfo/python-list
