A Python 3000 Question

[brad]

Will len(a_string) become a_string.len()? I was just reading

http://docs.python.org/dev/3.0/whatsnew/3.0.html

One of the criticisms of Python compared to other OO languages is that
it isn't OO enough or as OO as others or that it is inconsistent. And
little things such as this seem to support those arguments. Not that it
matters really... just seems that classes with methods used in a more
consistent manner would be more appropriate in an OO langauage. Is there
a reason that len cannot be a method?

a_string.lower() makes sense, as does a_string.split(),
a_string.strip()... why not a_string.len()?

 

[Rob Wolfe]

Will len(a_string) become a_string.len()? I was just reading

http://docs.python.org/dev/3.0/whatsnew/3.0.html

One of the criticisms of Python compared to other OO languages is that
it isn't OO enough or as OO as others or that it is inconsistent. And
little things such as this seem to support those arguments. Not that
it matters really... just seems that classes with methods used in a
more consistent manner would be more appropriate in an OO
langauage. Is there a reason that len cannot be a method?

a_string.lower() makes sense, as does a_string.split(),
a_string.strip()... why not a_string.len()?

I wonder why people always complain about `len` function but never
about `iter` or `pprint.pprint`?

And to answer the question. In OO programming generic functions
are no less important than classes and objects.

Regards,
Rob

 

[brad]

I wonder why people always complain about `len` function but never
about `iter` or `pprint.pprint`?

Not complaining. len is simple and understandable and IMO fits nicely
with split(), strip(), etc... that's why I used it as an example, but
list(), etc. could be used as examples as well:

a_string.list() instead of list(a_string)

And to answer the question. In OO programming generic functions
are no less important than classes and objects.

Do they not take away from the OOness of the overall language and
introduce inconsistencies?

 

[Terry Reedy]

| Will len(a_string) become a_string.len()?

No.

I was just reading
| http://docs.python.org/dev/3.0/whatsnew/3.0.html

which says nothing about such a change, except for one in the opposite
direction: o.next() changes to next(o) which in turn calls o.__next__(),
just as len(o) calls o.__len__()

| One of the criticisms of Python compared to other OO languages is that
| it isn't OO enough or as OO as others or that it is inconsistent.

Python is object-based and has a nice user-defined type (class) system, but
I do not believe Guido has ever called it object oriented. So the
comparision is besides the point even if true.

| Is there a reason that len cannot be a method?

It corresponds to and calls method .__len__ , when such exists. Yes,
Python could have been designed differently, with no builtin functions, but
is was not. Python is also a functional language with first-class generic
functions.

| why not a_string.len()?

You are free to bypass builtins and call methods directly if you like:
a_string.__len__().

But consider rewriting the following:

def table(func, seq):
return zip(seq, map(func,seq))

table(len, ('', (), []))

If you *really* want to be super-OO, like functionless OO languages, you
can also call methods instead of using operator symbols, which in effect
are names of builtin functions.

Instead of a+b, write a.__add__(b). And so on.

Terry Jan Reedy

 

[Bjoern Schliessmann]

One of the criticisms of Python compared to other OO languages is
that it isn't OO enough or as OO as others or that it is
inconsistent.

If OO meant "everything must be a method" then yes, Python wasn't
OO.

And little things such as this seem to support those
arguments. Not that it matters really... just seems that classes
with methods used in a more consistent manner would be more
appropriate in an OO langauage. Is there a reason that len cannot
be a method?

Is there any particular reason why it should be a method?

a_string.lower() makes sense, as does a_string.split(),
a_string.strip()... why not a_string.len()?

Just a fuzzy comment: lower, split and strip work specifically for
strings and/or sequence types, and return a modified copy of them
(or modify them directly, as with other methods like sorted or
shuffle). len, OTOH, works for much more objects and returns some
kind of norm that makes objects comparable and whose type is the
same for all objects.

To make a long story short: Most methods do specific things with
objects; but len is a common function to get a simple property of
an object.

Regards,


Björn

 

[Bjoern Schliessmann]

a_string.list() instead of list(a_string)

A string can be stripped, "lowercased" or split, but why should it
be able to be "listed"? IMHO, list is a conversion function to make
a list from something.

Do they not take away from the OOness of the overall language and
introduce inconsistencies?

Not at all. Explain, why should they? Functions can be objects, too.
And are in Python.

The inconsistencies arise, IMHO, if an OO language introduces
non-object types for performance reasons, after that gets wrapper
classes to wrap those primitives, and even later gets the ability
to automatically cast a primitive into a wrapper class instance.
That's just ugly.

Regards,


Björn

 

[Carl Banks]

One of the criticisms of Python compared to other OO languages is that
it isn't OO enough or as OO as others or that it is inconsistent.

Python is less thoroughly OO than some other languages, yes. The
underlying assumption, that being thoroughly OO is a good thing, is
very dubious.


Carl Banks

 

[Marc 'BlackJack' Rintsch]

Not complaining. len is simple and understandable and IMO fits nicely
with split(), strip(), etc... that's why I used it as an example, but
list(), etc. could be used as examples as well:

a_string.list() instead of list(a_string)

`list()` takes any iterable and turns it into a list object. That's a
generic operation coded *once*. If you have `str.list()`, `tuple.list()`,
`list.list()`, `dict.list()`, `file.list()`, `MyIterableSomething.list()`,
etc. you have to code the same over and over again for all those objects.
How could that be a benefit!?

Do they not take away from the OOness of the overall language and
introduce inconsistencies?

No not at all. Why do you think so? There are things that are best
expressed as functions. Other allegedly more OO languages have them
too, but you need to stuff them as static methods into classes or even
uglier you see code like ``Spam().spammify(eggs)`` instead of a plain
function call.

And functions are first class objects in Python. That sounds quite OO to
me. You can think of a module with functions as a singleton.

Ciao,
Marc 'BlackJack' Rintsch

 

[Wildemar Wildenburger]

The inconsistencies arise, IMHO, if an OO language introduces
non-object types for performance reasons, after that gets wrapper
classes to wrap those primitives, and even later gets the ability
to automatically cast a primitive into a wrapper class instance.
That's just ugly.

If you mean Java, then just say Java.


/W

 

[Michael L Torrie]

Not complaining. len is simple and understandable and IMO fits nicely
with split(), strip(), etc... that's why I used it as an example, but
list(), etc. could be used as examples as well:

a_string.list() instead of list(a_string)

This is a great example of why list() needs to be a singleton and *not*
a method of any particular class. Consider the following contrived
object (yes object):

def foo():
for x in xrange(6):
yield x


If we eliminated list() as a first class singleton and forced it to be a
method call, how would it work with this generator object? Right now I
can say:

mylist=list(foo())

Saying list() should be a method only of something iterable is not only
foolish, but wasteful. Why should I burden every iterable object with
redundant code? And how would you deal with generators in your scenario?

In short, making list() a method is wrong-thinking. Reminds me of java.
Ugg.

Do they not take away from the OOness of the overall language and
introduce inconsistencies?

If find Python to be more OO through and through than Java. Once you
understand that functions are objects, and duck-typing, things like
len() being a function rather than a method make perfect sense.

 

[George Sakkis]

I was just reading
|http://docs.python.org/dev/3.0/whatsnew/3.0.html

which says nothing about such a change, except for one in the opposite
direction: o.next() changes to next(o) which in turn calls o.__next__(),
just as len(o) calls o.__len__()

Ugh. A great example of complexification (if there's such a word).

| why not a_string.len()?

You are free to bypass builtins and call methods directly if you like:
a_string.__len__().

But consider rewriting the following:

def table(func, seq):
return zip(seq, map(func,seq))

table(len, ('', (), []))

table(lambda x:x.__len__(), ('',[],()))

What was the point again ?

If you *really* want to be super-OO, like functionless OO languages, you
can also call methods instead of using operator symbols, which in effect
are names of builtin functions.

Instead of a+b, write a.__add__(b). And so on.

True, if ones wants to go all the way to, say, Java. Operator
overriding though is pretty handy in terms of syntax sugar to give up,
especially for expressions that are identical or strongly similar from
a familiar context (e.g. maths). This cannot be claimed about len()
though. My main problem with len() is not so much the function/method
inconsistency, but rather that it doesn't apply to all (or even most)
objects. I am much less against, say, getattr(), being a function
since it makes sense for all objects. But why len()? At best it's a
subjective judgment call of where to draw the line, at worst it's
plain inconsistent.

And while we're at it, what's the rationale of len() insisting that
the return value is >=0 ? That also looks odd in a dynamic language
with a "we're all adults here" philosophy and much less hand-holding
in areas that matter more (e.g. allowed by default comparisons between
instances of different types - at least that's one of the warts Python
3 gets right).

George

 

[George Sakkis]

This is a great example of why list() needs to be a singleton and *not*
a method of any particular class.

The whole discussion about list() is moot since it's not a function
anyway, it's a type. As long as a list knows hows to initialize itself
given any iterable, it would be useless to require it as a method to
the iterables as well (unless perhaps there are significant
performance improvements when one can create a list much faster than
iterating through it).

Saying list() should be a method only of something iterable is not only
foolish, but wasteful. Why should I burden every iterable object with
redundant code?

Does the same argument apply for len() ? Nope, you still have to
define __len__. Having a builtin len() that calls the method __len__
seems (using your words) "not only foolish but wasteful".

In short, making list() a method is wrong-thinking. Reminds me of java.
Ugg.

Agreed, but you're beating a dead horse with list().

If find Python to be more OO through and through than Java. Once you
understand that functions are objects, and duck-typing, things like
len() being a function rather than a method make perfect sense.

Does the fact that index() or split() are methods make perfect sense
as well? I guess after some time using Python it does, but for most
unbiased users the distinction seems arbitrary.

George

 

[Marc 'BlackJack' Rintsch]

| why not a_string.len()?

You are free to bypass builtins and call methods directly if you like:
a_string.__len__().

But consider rewriting the following:

def table(func, seq):
return zip(seq, map(func,seq))

table(len, ('', (), []))

table(lambda x:x.__len__(), ('',[],()))

What was the point again ?

Beautiful is better than ugly!? ;-)

Ciao,
Marc 'BlackJack' Rintsch

 

[Thomas Wittek]

Bjoern Schliessmann:

Is there any particular reason why it should be a method?

[..]

To make a long story short: Most methods do specific things with
objects; but len is a common function to get a simple property of
an object.

You said it. IMHO it really could be a *property*, say `object.len`.
It doesn't do something on the object, but rather gives some information
about its "state".

 

[Bruno Desthuilliers]

brad a écrit :

Will len(a_string) become a_string.len()? I was just reading

http://docs.python.org/dev/3.0/whatsnew/3.0.html

One of the criticisms of Python compared to other OO languages is that
it isn't OO enough

Really ? IIRC, Python doesn't have primitive types, functions are
objects, methods are objects, classes are objects, even modules are
objects... Isn't this 'OO enough' ?

or as OO as others

Which ones ? Java, that does have primitive types ?

(snip question about len() not being a method - no personal opinion on
the topic)

 

[Bruno Desthuilliers]

brad a écrit :

Not complaining. len is simple and understandable and IMO fits nicely
with split(), strip(), etc... that's why I used it as an example, but
list(), etc. could be used as examples as well:

a_string.list() instead of list(a_string)

Oh, fine. And a_string.tuple(), a_string.int(), a_string.this(),
a_string.that() etc ?

In case you don't know, list is a type, not a function !-)

Do they not take away from the OOness of the overall language

Why so ?

and
introduce inconsistencies?

The monotonic approach to callables in Python (I mean: functions are
callable objects, classes are callable objects, so instanciation and
function call have the exact same syntax - which let you decouple
interface from implementation) is another way to be consistent. because
you can switch from type to factory function (or from closure to
callable object, etc) back and forth without breaking client code.

 

[Eduardo O. Padoan]

Will len(a_string) become a_string.len()? I was just reading

http://docs.python.org/dev/3.0/whatsnew/3.0.html

One of the criticisms of Python compared to other OO languages is that
it isn't OO enough or as OO as others or that it is inconsistent. And
little things such as this seem to support those arguments. Not that it
matters really... just seems that classes with methods used in a more
consistent manner would be more appropriate in an OO langauage. Is there
a reason that len cannot be a method?

a_string.lower() makes sense, as does a_string.split(),
a_string.strip()... why not a_string.len()?

This is a FAQ:
http://effbot.org/pyfaq/why-does-py...ndex-but-functions-for-other-e-g-len-list.htm

 

[Dustan]

If you mean Java, then just say Java.

There was no need to; it was heavily implied.

 

[brad]

This is a FAQ:
http://effbot.org/pyfaq/why-does-py...ndex-but-functions-for-other-e-g-len-list.htm

Thanks to all for the feedback. I'm no language designer. I just see and
hear these criticisms and I wanted to think through it a bit by posting
here. I now better understand generic functions and why they are used in
some cases.

 

[Steven D'Aprano]

No not at all. Why do you think so?

I disagree. I think they *do* take away from the overall Object-Oriented
nature of the language, and that is A Very Good Thing Indeed.

OO is a tool, and like any tool, it has it's uses and misuses. Some
things are best written as objects, some as imperative procedures, some
as functions. As you say:

There are things that are best expressed as functions.

Agreed. It is a *good thing* that Python doesn't try to be 100%
functional, or 100% Object Oriented, or 100% procedural.

(Aside: I think it a shame that there is one major paradigm that Python
doesn't have *any* support for at all: logic programming, like Prolog. I
don't quite know what it is good for, but I'd like to find out!)

Other allegedly more OO languages have them
too, but you need to stuff them as static methods into classes or even
uglier you see code like ``Spam().spammify(eggs)`` instead of a plain
function call.

I'm reminded of a very famous proverb from the Kingdom of the Nouns:

For the lack of a nail,
throw new HorseshoeNailNotFoundException("no nails!");

For the lack of a horseshoe,
EquestrianDoctor.getLocalInstance().getHorseDispatcher().shoot();

For the lack of a horse,
RidersGuild.getRiderNotificationSubscriberList().getBroadcaster().run(
new BroadcastMessage(StableFactory.getNullHorseInstance()));

For the rest of the proverb, which is well worth reading, you'll have to
see here:


http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html