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?

[Christian Heimes]

Re: What is not objects in Python?

process wrote:

What is not an object in Python?

Everything that is not part of Python's syntax is an object, including
all string and number types, classes, metaclasses, functions, models,
code and more. It's technically not possible to have something like e.g.
an int that isn't an object.

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

Because readability is more important than purity. By the way len(egg)
is just syntactic sugar for egg.__len__() with some extra checks.

[Lie]

Re: What is not objects in Python?

On Sep 29, 1:29 am, process <circularf...@g mail.comwrote:

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?

A question like this is often answered by another (rhetorical)
question: "What is Object Oriented actually?"

The answer to that is generally: "Python is not Java."

[Terry Reedy]

Re: What is not objects in Python?

process wrote:

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

Feel free to ignore it if you wish.

What is not an object in Python?

Depends on what you mean by 'in'. Python is a language for defining and
manipulating information objects. Code 'in' Python is not usually a
maniputed object, though is can be (by eval, exec, and compile, for
instance). Names in code that are only used to directly access objects
typically are also, typically, not objects themselves.

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

Partly history and partly practicality. Len is implemented as .__len__
;-). The len function is one, __len__ methods are many. If you want to
pass an argument to a function, passing len is easier that passing
operator.attrge tter('__len__') . Passing '__len__' (or 'len') would be
easy, but using len is easier than using getattr(ob,'__l en__').

tjr

[bearophileHUGS@lycos.com]

Re: What is not objects in Python?

Terry Reedy:

Partly history and partly practicality. Len is implemented as .__len__
;-). The len function is one, __len__ methods are many. If you want to
pass an argument to a function, passing len is easier that passing
operator.attrge tter('__len__') . Passing '__len__' (or 'len') would be
easy, but using len is easier than using getattr(ob,'__l en__').

A simple example may help:

>>seq = ["aaaa", "bb", "c", "ddd"]
>>seq2 = [[1,1,1,1], [2,2], [3], [4,4,4]]
>>sorted(seq, key=len)

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

>>sorted(seq2 , key=len)

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

>>sorted(seq, key=str.__len__ )

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

>>sorted(seq2 , key=str.__len__ )

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: descriptor '__len__' requires a 'str' object but received a
'list'

>>from operator import attrgetter
>>sorted(seq, key=attrgetter( "__len__"))

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

>>sorted(seq2 , key=attrgetter( "__len__"))

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

Bye,
bearophile

[sjdevnull@yahoo.com]

Re: What is not objects in Python?

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.
>
What is not an object in Python?
>

Parts of the syntax aren't objects. e.g. "=" or ":" aren't objects.

Unlike in some less fully OO-languages (e.g. Java or C++), classes,
functions, and many other "built-in language features" are objects in
Python. You can do things like return functions just like any other
object, rather than having to do it indirectly through references or
some such:

>>def add_n(x):

.... def rv(y):
.... return y + x
.... return rv
....

>>add_2 = add_n(2)
>>add_3 = add_n(3)
>>>
>>print add_2(6)

8

>>print add_2(10)

12

>>print add_3(6)

9

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

FWIW, it is implemented as a str.__len__ method (and list.__len__
method); the len() function just uses those internally. Java and C++
have similar shortcuts for, say, "+" or "-". But Python allows you to
call all the operators as methods if you want:

>>1+2

3

>>(1).__add__(2 )

3

>>a_list = [ "a", "b", "c" ]
>>len(a_list)

3

>>a_list.__len_ _()

3


And, of course, the presence of the len() shortcut doesn't alter the
OO-nature of the language any more than the presence of the + operator
does in any OO language. Derived classes' __len__ operators are
called correctly by len():

>>class list_that_lies( list):

.... def __len__(self):
.... return 2
....

>>bad_list=list _that_lies([1,2])
>>print bad_list

[1, 2]

>>len(bad_lis t)

2

>>bad_list.appe nd(3)
>>print bad_list

[1, 2, 3]

>>len(bad_lis t)

2

[Tim Rowe]

Re: What is not objects in Python?

2008/9/28 process <circularfunc@g mail.com>:

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

Why is that a criticism? OO is a tool, not a religion (ok, ok, OO
*should be* a tool, not a religion). Is it a criticism of a hammer
that it is not a screwdriver? Or do you pick the tool that does the
job in hand most effectively?

--
Tim Rowe

[Carl Banks]

Re: What is not objects in Python?

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

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

Although len() is spelled like a function call, in spirit it's an
operator, and it behaves like any other operator in Python.

Never mind why len() is an operator and not a method in Python, the
point is, just as operators like + doesn't make a language less object-
oriented (C++ would be very surprised to find out that it's not OO),
neither do operator functions like len().

Having said that, I encourage you to understanda a language for what
it is, not for whatever computer science buzzword labels it has.


Carl Banks

[George Sakkis]

Re: What is not objects in Python?

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

George

[Terry Reedy]

Re: What is not objects in Python?

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). Methods that apply
to one class (or just couple) are called as non-special methods. I am
not sure why del is a statement rather than a function -- perhaps just
because there is no return value (other than the default None).

tjr

[George Sakkis]

Re: What is not objects in Python?

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]

Re: What is not objects in Python?

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]

Re: What is not objects in Python?

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@lycos.com]

Re: What is not objects in Python?

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]

Re: What is not objects in Python?

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