469,283 Members | 2,166 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,283 developers. It's quick & easy.

What is not objects in Python?

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?
Sep 28 '08 #1
41 1423
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.

Sep 28 '08 #2
Lie
On Sep 29, 1:29*am, process <circularf...@gmail.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."
Sep 28 '08 #3
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.attrgetter('__len__'). Passing '__len__' (or 'len') would be
easy, but using len is easier than using getattr(ob,'__len__').

tjr


Sep 28 '08 #4
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.attrgetter('__len__'). Passing '__len__' (or 'len') would be
easy, but using len is easier than using getattr(ob,'__len__').
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
Sep 28 '08 #5
On Sep 28, 2:29 pm, process <circularf...@gmail.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_list)
2
>>bad_list.append(3)
print bad_list
[1, 2, 3]
>>len(bad_list)
2

Sep 28 '08 #6
2008/9/28 process <ci**********@gmail.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
Sep 28 '08 #7
On Sep 28, 2:29*pm, process <circularf...@gmail.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
Sep 28 '08 #8
On Sep 28, 2:29*pm, process <circularf...@gmail.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
Sep 28 '08 #9
George Sakkis wrote:
On Sep 28, 2:29 pm, process <circularf...@gmail.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

Sep 29 '08 #10
On Sep 29, 12:08 am, Terry Reedy <tjre...@udel.eduwrote:
George Sakkis wrote:
On Sep 28, 2:29 pm, process <circularf...@gmail.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
Sep 29 '08 #11
On Sep 29, 1:44*am, George Sakkis <george.sak...@gmail.comwrote:
On Sep 29, 12:08 am, Terry Reedy <tjre...@udel.eduwrote:
George Sakkis wrote:
On Sep 28, 2:29 pm, process <circularf...@gmail.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 "philosophical" 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
Sep 29 '08 #12
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.eduwrote:
George Sakkis wrote:
On Sep 28, 2:29 pm, process <circularf...@gmail.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 "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
Sep 29 '08 #13
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
Sep 29 '08 #14
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
Sep 29 '08 #15
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.

Sep 29 '08 #16
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
Sep 29 '08 #17
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
Sep 29 '08 #18
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
Sep 29 '08 #19
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

Sep 29 '08 #20
On Mon, 29 Sep 2008 05:41:02 -0700, George Sakkis wrote:
For example I would be much less
opposed to len() being defined as, say, |x| if "|...|" was a valid
operator.
Arghh! No!!! |x| should be abs(x), not len(x). Just ask mathematicians
and physicists.

*wink*

Actually there's a serious point there. There aren't that many
unambiguous operators that are available on a standard keyboard that
(nearly) everyone can agree on.
--
Steven
Sep 29 '08 #21
Steven D'Aprano wrote:
On Mon, 29 Sep 2008 05:41:02 -0700, George Sakkis wrote:
>For example I would be much less
opposed to len() being defined as, say, |x| if "|...|" was a valid
operator.

Arghh! No!!! |x| should be abs(x), not len(x). Just ask mathematicians
and physicists.
It should be both, just as + is addition for numbers and concatenation
for sequences. Or we could have just one built-in -- size() instead of
abs() and len(). For non-sequence collections, size() would be better
than len() anyway.

tjr

Sep 30 '08 #22
On 28 set, 15:29, process <circularf...@gmail.comwrote:
I have heard some criticism about Python, that it is not fully object-
oriented.
So what?
Why isn't len implemented as a str.len and list.len method instead of
a len(list) function?
Because postfix notation sucks. The natural way of spelling is
adjective+noun and verb+predicate. That's one of the reasons I like
Lisp better than Python.
Sep 30 '08 #23
In article <ma**************************************@python.o rg>,
Terry Reedy <tj*****@udel.eduwrote:
It should be both, just as + is addition for numbers and concatenation
for sequences.
Actually, the math folks would argue that using + for concatenation is
wrong, since by normal math rules, + denotes a commutative operation.

Of course, the math folks think that i^2 = -1, so what do they know? All
right-thinking people know that j^2 = -1.
Sep 30 '08 #24
On Mon, 29 Sep 2008 21:03:07 -0700, namekuseijin wrote:
>Why isn't len implemented as a str.len and list.len method instead of a
len(list) function?

Because postfix notation sucks. The natural way of spelling is
adjective+noun and verb+predicate.
"Natural"?

You mean phrases like "heir apparent" and "worst choice imaginable" are
unnatural? To say nothing of languages like Spanish, Albanian, Italian,
Cornish, Vietnamese, Hebrew...

--
Steven
Sep 30 '08 #25
En Tue, 30 Sep 2008 01:03:07 -0300, namekuseijin <na**********@gmail.com>
escribió:
On 28 set, 15:29, process <circularf...@gmail.comwrote:
>Why isn't len implemented as a str.len and list.len method instead of
a len(list) function?

Because postfix notation sucks. The natural way of spelling is
adjective+noun and verb+predicate. That's one of the reasons I like
Lisp better than Python.
Well, "natural" for English-speaking people... Noun+adjective is usually
more "natural" In Spanish than the English word ordering.

Back to the original question, len(x) allows for a fast response without
paying the overhead of a name lookup and then a method call.
len(some_list) doesn't invoke some_list.__len__(), it just returns the
value stored somewhere in the list object; same for other built-in
objects. __len__ is searched as a last resort only.
The optimization could not be done if it were spelled x.len()

--
Gabriel Genellina

Sep 30 '08 #26
Terry Reedy wrote:
Steven D'Aprano wrote:
>On Mon, 29 Sep 2008 05:41:02 -0700, George Sakkis wrote:
>>For example I would be much less
opposed to len() being defined as, say, |x| if "|...|" was a valid
operator.

Arghh! No!!! |x| should be abs(x), not len(x). Just ask mathematicians
and physicists.

It should be both, just as + is addition for numbers and concatenation
for sequences. Or we could have just one built-in -- size() instead of
abs() and len(). For non-sequence collections, size() would be better
than len() anyway.
And how are these "non-sequence collections" to be distinguished? And
how does size() differ from len() in that case?

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Sep 30 '08 #27
On Mon, 2008-09-29 at 21:03 -0700, namekuseijin wrote:
On 28 set, 15:29, process <circularf...@gmail.comwrote:
I have heard some criticism about Python, that it is not fully object-
oriented.

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

Because postfix notation sucks. The natural way of spelling is
adjective+noun and verb+predicate. That's one of the reasons I like
Lisp better than Python.
--
http://mail.python.org/mailman/listinfo/python-list
Actually str.len and len(str) is just like saying "the string's length"
and "the length of the string". There is no difference between the two
except for personal preference. (I am no linguist-- not even a native
speaker of English --but I think there is a subtle difference on
emphasis, "the string's length" emphasizes on the length being string's
property, while "the length of the string" emphasizes on the length
itself, am I correct?)
Sep 30 '08 #28
Steven D'Aprano wrote:
On Mon, 29 Sep 2008 21:03:07 -0700, namekuseijin wrote:
>>Why isn't len implemented as a str.len and list.len method instead of a
len(list) function?
Because postfix notation sucks. The natural way of spelling is
adjective+noun and verb+predicate.

"Natural"?

You mean phrases like "heir apparent" and "worst choice imaginable" are
unnatural?
They are certainly far from normal usage, as my dog yellow would be
certain to agree.
To say nothing of languages like Spanish, Albanian, Italian,
Cornish, Vietnamese, Hebrew...
It's long been a convention in the Western programming world to pretend
no other language than English and no other codes than ASCII exist.

The fact that Python is beginning to come to terms with Unicode is a
tribute to certain developers' persistence.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Sep 30 '08 #29
Steven D'Aprano wrote:
On Mon, 29 Sep 2008 21:03:07 -0700, namekuseijin wrote:
>>Why isn't len implemented as a str.len and list.len method instead of a
len(list) function?
Because postfix notation sucks. The natural way of spelling is
adjective+noun and verb+predicate.

"Natural"?

You mean phrases like "heir apparent" and "worst choice imaginable" are
unnatural?
They are certainly far from normal usage, as my dog yellow would be
certain to agree.
To say nothing of languages like Spanish, Albanian, Italian,
Cornish, Vietnamese, Hebrew...
It's long been a convention in the Western programming world to pretend
no other language than English and no other codes than ASCII exist.

The fact that Python is beginning to come to terms with Unicode is a
tribute to certain developers' persistence.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

Sep 30 '08 #30
En Tue, 30 Sep 2008 08:07:18 -0300, Steve Holden <st***@holdenweb.com>
escribió:
Terry Reedy wrote:
>Steven D'Aprano wrote:
>>Arghh! No!!! |x| should be abs(x), not len(x). Just ask mathematicians
and physicists.

It should be both, just as + is addition for numbers and concatenation
for sequences. Or we could have just one built-in -- size() instead of
abs() and len(). For non-sequence collections, size() would be better
than len() anyway.
And how are these "non-sequence collections" to be distinguished? And
how does size() differ from len() in that case?
Consider a tree, or a graph. The number of elements they have is not
naturally described as their "length", the usual term is "size" instead.
"Length" is adequate for one-dimensional structures only; even len(dict)
is a bit controversial.
Had Python used the more generic size and __size__ from the beginning,
we'd be all happy now :) But it's too late to change things.

--
Gabriel Genellina

Sep 30 '08 #31
On Sep 30, 7:39*am, Steve Holden <st...@holdenweb.comwrote:
Steven D'Aprano wrote:
On Mon, 29 Sep 2008 21:03:07 -0700, namekuseijin wrote:
>Why isn't len implemented as a str.len and list.len method instead ofa
len(list) function?
Because postfix notation sucks. *The natural way of spelling is
adjective+noun and verb+predicate.
"Natural"?
You mean phrases like "heir apparent" and "worst choice imaginable" are
unnatural?

They are certainly far from normal usage, as my dog yellow would be
certain to agree.
To say nothing of languages like Spanish, Albanian, Italian,
Cornish, Vietnamese, Hebrew...

It's long been a convention in the Western programming world to pretend
no other language than English and no other codes than ASCII exist.

The fact that Python is beginning to come to terms with Unicode is a
tribute to certain developers' persistence.

regards
*Steve
--
Steve Holden * * * *+1 571 484 6266 * +1 800 494 3119
Holden Web LLC * * * * * * *http://www.holdenweb.com/
How do you have a yellow dog, and what does s/he know about natural
noun-verb usage?
Oct 1 '08 #32
42, for instance.

Proof :
>>42 is not object
True

QED

Oct 1 '08 #33
On Wed, 01 Oct 2008 17:56:34 +0200, Boris Borcic wrote:
42, for instance.

Proof :
>>42 is not object
True

QED
>>isinstance(42, object)
True

--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- pass it on
Oct 2 '08 #34
Gabriel Genellina wrote:
Had Python used the more generic size and __size__ from the beginning,
we'd be all happy now :)
Not necessarily -- len is slightly shorter, and more
comfortable to type on a qwerty keyboard.

But in any case, size-likers have an easy solution:

size = len

:-)

(BTW, try doing that with the x.len() notation!)

--
Greg
But it's too late to change things.
>
Oct 3 '08 #35
Aaron "Castironpi" Brady wrote:
How do you have a yellow dog,
It's not a yellow dog, it's a dog yellow. Attention pay! :-)

--
Ewing Gregory
Oct 3 '08 #36
On Fri, 03 Oct 2008 19:10:27 +1200, greg wrote:
But in any case, size-likers have an easy solution:

size = len

:-)

(BTW, try doing that with the x.len() notation!)
def size(obj):
return obj.len()

or

size = operator.methodcaller('len')

in Python 2.6 and up.

:-)

Ciao,
Marc 'BlackJack' Rintsch
Oct 3 '08 #37
Boris Borcic a écrit :
42, for instance.

Proof :
>>42 is not object
True

QED
Lol.
Oct 3 '08 #38
2008/9/30 Lie Ryan <li******@gmail.com>:
Actually str.len and len(str) is just like saying "the string's length"
and "the length of the string". There is no difference between the two
except for personal preference. (I am no linguist-- not even a native
speaker of English --but I think there is a subtle difference on
emphasis, "the string's length" emphasizes on the length being string's
property, while "the length of the string" emphasizes on the length
itself, am I correct?)
Well, I'm doing a linguistics degree, so I'm not a linguist /yet/, but
I think I know this one. There is the difference in emphasis that you
mention, but there may be something more significant. In both forms,
"length" is what linguists call the "head" of the noun phrase: it's
the actual thing being talked about. In "The string's length" the
head is only pre-modified ("the string's" comes before the head and
there's nothing after the head). "The length of the string" has both
pre- and post- modification ("The" before, "of the string" after).
Post modification in noun phrases has been measured to be much less
frequent in spoken English than in written English, and it gets
progressively more common as the writing style gets more formal. That
suggests that "the string's length" is an easier phrase to produce and
understand, but "the length of the string" sounds more official.

--
Tim Rowe
Oct 3 '08 #39
On Oct 3, 5:10*am, "Tim Rowe" <digi...@gmail.comwrote:
2008/9/30 Lie Ryan <lie.1...@gmail.com>:
Actually str.len and len(str) is just like saying "the string's length"
and "the length of the string". There is no difference between the two
except for personal preference. (I am no linguist-- not even a native
speaker of English --but I think there is a subtle difference on
emphasis, "the string's length" emphasizes on the length being string's
property, while "the length of the string" emphasizes on the length
itself, am I correct?)

Well, I'm doing a linguistics degree, so I'm not a linguist /yet/, but
I think I know this one. There is the difference in emphasis that you
mention, but there may be something more significant. In both forms,
"length" is what linguists call the "head" of the noun phrase: it's
the actual thing being talked about. *In "The string's length" the
head is only pre-modified ("the string's" comes before the head and
there's nothing after the head). "The length of the string" has both
pre- and post- modification ("The" before, "of the string" after).
Post modification in noun phrases has been measured to be much less
frequent in spoken English than in written English, and it gets
progressively more common as the writing style gets more formal. *That
suggests that "the string's length" is an easier phrase to produce and
understand, but "the length of the string" sounds more official.

--
Tim Rowe
.... Unless, there is some corresponding distinction in mechanics
between speaking and writing. That is, if something about the process
of generating writing makes it, post-modification, easier. I'm going
to assume that it's been observed across all modes of writing too, (in
addition to across all formality levels), where in all cases it was
equally easy to go back and edit, which is impossible in speech. And,
in the cases where the entire process of writing was observed, that
neither kind of modification occurred more frequently in revisions.
Oct 3 '08 #40
... Unless, there is some corresponding distinction in mechanics
between speaking and writing. That is, if something about the process
of generating writing makes it, post-modification, easier. I'm going
to assume that it's been observed across all modes of writing too, (in
addition to across all formality levels), where in all cases it was
equally easy to go back and edit, which is impossible in speech. And,
in the cases where the entire process of writing was observed, that
neither kind of modification occurred more frequently in revisions.
There are such distinctions. In writing, more time is available to
produce the text, there is the opportunity to revise the text, the
reader has more time to read the text and the reader has the
opportunity to re-read the text. Unfortunately, because of the "more
time is available to produce the text", observing the writing process
would be of limited value.

I don't think it's that post-modification becomes easier than
pre-modification in writing, I think it's that post-modification
becomes more feasible in writing, and is preferred for stylistic
reasons.

When you say "across all modes of writing" I'm not sure what you mean
(linguistically, writing /is/ the mode!) -- I suspect you mean either
register (style of writing) or medium (loosely, method of writing).
Oct 3 '08 #41
Marc 'BlackJack' Rintsch wrote:
On Fri, 03 Oct 2008 19:10:27 +1200, greg wrote:
>>(BTW, try doing that with the x.len() notation!)
def size(obj):
return obj.len()

or

size = operator.methodcaller('len')
No, what I meant was that if the normal way of getting
the len of something were to write x.len() instead of
len(x), you wouldn't be able to globally substitute
that syntax with x.size().

--
Greg
Oct 5 '08 #42

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Ng Pheng Siong | last post: by
220 posts views Thread by Brandon J. Van Every | last post: by
54 posts views Thread by Brandon J. Van Every | last post: by
28 posts views Thread by David MacQuigg | last post: by
2 posts views Thread by Sells, Fred | last post: by
137 posts views Thread by Philippe C. Martin | last post: by
21 posts views Thread by godwin | last post: by
4 posts views Thread by Gre7g Luterman | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.