What is not objects in Python?

[process]

I have heard some criticism about Python, that it is not fully object-
oriented.

What is not an object in Python?

Why isn't len implemented as a str.len and list.len method instead of
a len(list) function?

[George Sakkis]

On Sep 29, 12:08 am, Terry Reedy <tjre...@udel.e duwrote:

George Sakkis wrote:

On Sep 28, 2:29 pm, process <circularf...@g mail.comwrote:

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".

George

[Carl Banks]

On Sep 29, 1:44*am, George Sakkis <george.sak...@ gmail.comwrote:

On Sep 29, 12:08 am, Terry Reedy <tjre...@udel.e duwrote:

George Sakkis wrote:

On Sep 28, 2:29 pm, process <circularf...@g mail.comwrote:

>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 "philosophi cal" as
"clear cut" (a definition I'm not sure many would agree with).

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.
Carl Banks

[George Sakkis]

On Sep 29, 2:34*am, Carl Banks <pavlovevide... @gmail.comwrote :

On Sep 29, 1:44*am, George Sakkis <george.sak...@ gmail.comwrote:

On Sep 29, 12:08 am, Terry Reedy <tjre...@udel.e duwrote:

George Sakkis wrote:
On Sep 28, 2:29 pm, process <circularf...@g mail.comwrote:

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 insteadof
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 writingit
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 "philosophi cal" 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

[bearophileHUGS]

George Sakkis:

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.

I have shown few usage examples of the len() one of the posts in this
thread. Can you take a look at them and show how you can better
rewrite them without a len function?

Bye,
bearophile

[George Sakkis]

On Sep 29, 9:02 am, bearophileH...@ lycos.com wrote:

George Sakkis:

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.

I have shown few usage examples of the len() one of the posts in this
thread. Can you take a look at them and show how you can better
rewrite them without a len function?

Bye,
bearophile

You mean this ?

>>seq = ["aaaa", "bb", "c", "ddd"]
seq2 = [[1,1,1,1], [2,2], [3], [4,4,4]]
sorted(seq, key=lambda x:x.__len__())

['c', 'bb', 'ddd', 'aaaa']

>>sorted(seq2 , key=lambda x:x.__len__())

[[3], [2, 2], [4, 4, 4], [1, 1, 1, 1]]

Sure, "len" looks better than lambda x:x.__len__(), but the same would
be true if there was an "upper" builtin for the following example:

>>s = ['a', 'd', 'B', 'C']
s2 = [u'a', u'd', u'B', u'C']
upper = lambda x: x.upper()
sorted(s, key=upper)

['a', 'B', 'C', 'd']

>>sorted(s2, key=upper)

[u'a', u'B', u'C', u'd']

No difference in principle, just len() happens to be implemented more
often than upper().

George

[Mel]

George Sakkis wrote:

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 )".

`del x` has almost nothing to do with `x`, and almost everything to do with
a namespace containing `x`. The object doesn't know what namespace it's
in.

Mel.

[Marc 'BlackJack' Rintsch]

On Mon, 29 Sep 2008 11:14:36 -0400, Mel wrote:

George Sakkis wrote:

>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 )".

`del x` has almost nothing to do with `x`, and almost everything to do
with a namespace containing `x`. The object doesn't know what namespace
it's in.

But George's example was ``del x[i]`` which *has* something to do with
`x` as it mutates the object (or at least calls `x.__delitem__( )`).

Ciao,
Marc 'BlackJack' Rintsch

[bearophileHUGS]

George Sakkis:

No difference in principle, just len() happens to be implemented more
often than upper().

That's an important point. In a language that tries to be both
practical, readable, and elegant, the things that are done more may
deserve some sugar, to avoid code like this in many cases:

sorted(seq, key=lambda x:x.__len__())

Bye,
bearophile

[George Sakkis]

On Sep 29, 11:37 am, bearophileH...@ lycos.com wrote:

George Sakkis:

No difference in principle, just len() happens to be implemented more
often than upper().

That's an important point. In a language that tries to be both
practical, readable, and elegant, the things that are done more may
deserve some sugar, to avoid code like this in many cases:

sorted(seq, key=lambda x:x.__len__())

If this was the most compelling use case of having len as builtin, I
would be even less convinced. How often do you sort by len? FWIW, the
most common sorting keys I see in real world are attrgetter(some _attr)
or itemgetter(some _index) and both are imported functions, not
builtins.

George

[Terry Reedy]

George Sakkis wrote:

Sure, "len" looks better than lambda x:x.__len__(), but the same would
be true if there was an "upper" builtin for the following example:

>>>s = ['a', 'd', 'B', 'C']
s2 = [u'a', u'd', u'B', u'C']
upper = lambda x: x.upper()
sorted(s, key=upper)

['a', 'B', 'C', 'd']

>>>sorted(s2, key=upper)

[u'a', u'B', u'C', u'd']

No difference in principle, just len() happens to be implemented more
often than upper().

I disagree. One versus many classes is a principle. If a method is
used on objects of just one class, the class attribute can be used and
passed directly.

sorted(s, key = str.upper)
sorted(s2, key = unicode.upper)

The problem is having two text classes, which Guido considers to be a
mess and which Python did not have originally and which 3.0 also does
not have, even though bytes keeps the string methods. Mixing int, long,
and float numbers is or should be more common than mixing str and
unicode strings, and certainly more common than mixing str strings and
bytes in 3.0 (which is actively discouraged).

To me, discerning the implicit principles of Python's design makes it
easier to learn and remember, even if they are not as exact as one might
like. The choices are not random, and so one can do better than rote
memory.

Terry Jan Reedy