What is not objects in Python?

[George Sakkis]

On Sep 29, 2:34 am, Carl Banks <pavlovevide... at gmail.com> wrote:
> On Sep 29, 1:44 am, George Sakkis <george.sak... at gmail.com> wrote:
>
>
>
> > On Sep 29, 12:08 am, Terry Reedy <tjre... at udel.edu> wrote:
>
> > > George Sakkis wrote:
> > > > On Sep 28, 2:29 pm, process <circularf... at gmail.com> 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