len() and PEP 3000

[Thomas Guettler]

Hi,

The function len() is not mentioned in the Python 3000 PEPs.

I suggest that at least lists, tupples, sets, dictionaries and strings
get a len() method. I think the len function can stay, removing it
would break to much code. But adding the method, would bu usefull.

Yes, I know, that I can call .__len__() but that is ugly.

I have read the FAQ to the len function:
http://www.python.org/doc/faq/gener...st-index-but-functions-for-other-e-g-len-list

 

[Bjoern Schliessmann]

I suggest that at least lists, tupples, sets, dictionaries and
strings get a len() method.
Why?

I think the len function can stay, removing it would break to much
code. But adding the method, would bu usefull.

Yes, I know, that I can call .__len__() but that is ugly.

That's what len() is for.

Regards,


Björn

 

[Kay Schluehr]

Why?

Pro: Because it makes the API more monotonous and more aligned with all
other OO languages that exist now and in future. It also helps any
written and unwritten IDE providing a method by means of
autocompletion. It ends endless debates with Java/C++/C# etc. and
newbie Python programmers about this minor issue.

Contra: Having both __len__ ( for providing a generic function by
duality ) and len in the API is unpleasant.

But maybe one can drop all __special__ methods and use a decorator to
express duality between methods and functions?

class M:
@generic
def foo(self):
print "foo"
"foo"

And since we are at it. Why not also dropping __add__, __radd__,
__plus__ etc. for:

class M:
def binary+(self, other): # replaces __add__
...

def r_binary+(self, other): # replaces __radd__
...

def unary+(self, other): # replaces __plus__
...

 

[Bjoern Schliessmann]

Pro: Because it makes the API more monotonous and more aligned
with all other OO languages that exist now and in future. It also
helps any written and unwritten IDE providing a method by means of
autocompletion. It ends endless debates with Java/C++/C# etc. and
newbie Python programmers about this minor issue.

Contra: It makes the API more aligned with some other OO languages
and moves the focus from "the python way" to "the way it's always
been done".

Regards,


Björn

 

[Beliavsky]

Hi,

The function len() is not mentioned in the Python 3000 PEPs.

I suggest that at least lists, tupples, sets, dictionaries and strings
get a len() method. I think the len function can stay, removing it
would break to much code. But adding the method, would bu usefull.

Yes, I know, that I can call .__len__() but that is ugly.

I agree with you -- a.__len__() is ugly compared to len(a) . I am
surprised that such common idioms as len(a) may be going away. It is a
virtue of Python that it supports OOP without forcing OOP syntax upon
the user. How can one be confident that Python code one writes now has
a future?

 

[Klaas]

I agree with you -- a.__len__() is ugly compared to len(a) . I am
surprised that such common idioms as len(a) may be going away. It is a
virtue of Python that it supports OOP without forcing OOP syntax upon
the user. How can one be confident that Python code one writes now has
a future?

len() is not going away.

-MIke

 

[Fredrik Lundh]

I agree with you -- a.__len__() is ugly compared to len(a) . I am
surprised that such common idioms as len(a) may be going away.

no need to; the fact that something isn't currently mentioned in a
preliminary Python 3000 PEP doesn't mean that it will be removed.

</F>

 

[Giovanni Bajo]

I have read the FAQ to the len function:
http://www.python.org/doc/faq/gener...st-index-but-functions-for-other-e-g-len-list

Outdated. You want to read the new FAQ, here:
http://effbot.org/pyfaq/why-does-py...ndex-but-functions-for-other-e-g-len-list.htm

 

[Colin J. Williams]

Outdated. You want to read the new FAQ, here:
http://effbot.org/pyfaq/why-does-py...ndex-but-functions-for-other-e-g-len-list.htm

Why not replace the __len__ method with a len property for strings,
lists, tuples, dictionaries etc. __len__ is not very special and the
property len eliminates the redundant parentheses.

Colin W.

 

[bearophileHUGS]

Colin J. Williams:

Why not replace the __len__ method with a len property for strings,
lists, tuples, dictionaries etc. __len__ is not very special and the
property len eliminates the redundant parentheses.

You mean something like:

"ab".len, [1, 2, 3].len

(2, 3)

In the given page Guido says:

I didn't want these special operations to use ordinary method names, because then pre-existing classes, or classes written by users without an encyclopedic memory for all the special methods, would be liable to accidentally define operations they didn't mean to implement, with possibly disastrous consequences.<

I think it's easy enough to remember a len attribute, you use it all
the time.

many functions are defined in terms of informal interfaces; for example, reversed works on anything that supports random access to items and has a known length. In practice, implementing things like max, sum, map, any, in and others, as built-in functions and operators is actually less code than implementing them as methods for each and every type that needs to support them.<

I agree, but I think some exceptions can be made for len attribute, and
for .copy(), .deepcopy(), and maybe for few other general methods.

Bye,
bearophile

 

[tac-tics]

__len__ is not very special and the

property len eliminates the redundant parentheses.

One might say the current syntax eliminates the redundant dot.

 

[Colin J. Williams]

One might say the current syntax eliminates the redundant dot.

touché

On the other hand, one can argue that, since len is intimately
associated with an object, it's better treated as an attribute/property
than to have an unconnected function out in namespace.

Colin W.

 

[Fredrik Lundh]

On the other hand, one can argue that, since len is intimately
associated with an object, it's better treated as an attribute/property
than to have an unconnected function out in namespace.

"unconnected" ???

</F>

 

[Ross Ridge]

__len__ is not very special and the
property len eliminates the redundant parentheses.

One might say the current syntax eliminates the redundant dot.

Make "len" an operator, like C's "sizeof", and eliminate the
(hypothetical) dot, parenthesises and a name lookup.

Ross Ridge

 

[Klaas]

(hypothetical) dot, parenthesises and a name lookup.

Detect when a container is used in scalar context, and divine that the
length is requested.

We can think of arbitrarily-stupid ways of changing the perfectly
functional len(), but since it isn't going to change, why not drop this
topic?

-Mike

 

[Bjoern Schliessmann]

We can think of arbitrarily-stupid ways of changing the perfectly
functional len(), but since it isn't going to change, why not drop
this topic?

Don't read my mind again!

Regards,


Björn

 

[Ross Ridge]

We can think of arbitrarily-stupid ways of changing the perfectly
functional len(), but since it isn't going to change, why not drop this
topic?

I dunno, why didn't you?

Ross Ridge