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?
| | | | re: What is not objects in Python?
process wrote: Quote:
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. Quote:
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. | | | | re: What is not objects in Python?
On Sep 29, 1:29*am, process <circularf...@gmail.comwrote: Quote:
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." | | | | re: What is not objects in Python?
process wrote: Quote:
I have heard some criticism about Python, that it is not fully object-
oriented.
Feel free to ignore it if you wish. Quote:
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. Quote:
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 | | | | re: What is not objects in Python?
Terry Reedy: Quote:
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: Quote: Quote: Quote:
>>seq = ["aaaa", "bb", "c", "ddd"]
>>seq2 = [[1,1,1,1], [2,2], [3], [4,4,4]]
>>sorted(seq, key=len)
['c', 'bb', 'ddd', 'aaaa'] Quote: Quote: Quote:
>>sorted(seq2, key=len)
[[3], [2, 2], [4, 4, 4], [1, 1, 1, 1]] Quote: Quote: Quote:
>>sorted(seq, key=str.__len__)
['c', 'bb', 'ddd', 'aaaa'] Quote: Quote: Quote:
>>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' Quote: Quote: Quote:
>>from operator import attrgetter
>>sorted(seq, key=attrgetter("__len__"))
['aaaa', 'bb', 'c', 'ddd'] Quote: Quote: Quote:
>>sorted(seq2, key=attrgetter("__len__"))
[[1, 1, 1, 1], [2, 2], [3], [4, 4, 4]]
Bye,
bearophile | | | | re: What is not objects in Python?
On Sep 28, 2:29 pm, process <circularf...@gmail.comwrote: Quote:
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 rv(y):
.... return y + x
.... return rv
.... Quote: Quote: Quote:
>>add_2 = add_n(2)
>>add_3 = add_n(3)
>>>
>>print add_2(6)
8 12 9 Quote:
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: 3 3 Quote: Quote: Quote:
>>a_list = [ "a", "b", "c" ]
>>len(a_list)
3 Quote: Quote: Quote:
>>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(): Quote: Quote: Quote:
>>class list_that_lies(list):
.... def __len__(self):
.... return 2
.... Quote: Quote: Quote:
>>bad_list=list_that_lies([1,2])
>>print bad_list
[1, 2] 2 Quote: Quote: Quote:
>>bad_list.append(3)
>>print bad_list
[1, 2, 3] 2 | | | | re: What is not objects in Python?
2008/9/28 process <circularfunc@gmail.com>: Quote:
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 | | | | re: What is not objects in Python?
On Sep 28, 2:29*pm, process <circularf...@gmail.comwrote: Quote:
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 | | | | re: What is not objects in Python?
On Sep 28, 2:29*pm, process <circularf...@gmail.comwrote: Quote:
I have heard some criticism about Python, that it is not fully object-
oriented.
That's not a bug, it's a feature ;-) Quote:
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 | | | | re: What is not objects in Python?
George Sakkis wrote: Quote:
On Sep 28, 2:29 pm, process <circularf...@gmail.comwrote:
> Quote:
>I have heard some criticism about Python, that it is not fully object-
>oriented.
>
That's not a bug, it's a feature ;-)
> Quote:
>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 | | | | re: What is not objects in Python?
On Sep 29, 12:08 am, Terry Reedy <tjre...@udel.eduwrote: Quote:
George Sakkis wrote: Quote:
On Sep 28, 2:29 pm, process <circularf...@gmail.comwrote:
> Quote: Quote:
I have heard some criticism about Python, that it is not fully object-
oriented.
> Quote:
That's not a bug, it's a feature ;-)
> Quote: Quote:
Why isn't len implemented as a str.len and list.len method instead of
a len(list) function?
> Quote:
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 | | | | re: What is not objects in Python?
On Sep 29, 1:44*am, George Sakkis <george.sak...@gmail.comwrote: Quote:
On Sep 29, 12:08 am, Terry Reedy <tjre...@udel.eduwrote:
>
>
> Quote:
George Sakkis wrote: Quote:
On Sep 28, 2:29 pm, process <circularf...@gmail.comwrote:
> Quote: Quote:
>I have heard some criticism about Python, that it is not fully object-
>oriented.
> Quote: Quote:
That's not a bug, it's a feature ;-)
> Quote: Quote:
>Why isn't len implemented as a str.len and list.len method instead of
>a len(list) function?
> Quote: Quote:
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)".
> Quote:
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 | | | | re: What is not objects in Python?
On Sep 29, 2:34*am, Carl Banks <pavlovevide...@gmail.comwrote: Quote:
On Sep 29, 1:44*am, George Sakkis <george.sak...@gmail.comwrote:
>
>
> Quote:
On Sep 29, 12:08 am, Terry Reedy <tjre...@udel.eduwrote:
> Quote: Quote:
George Sakkis wrote:
On Sep 28, 2:29 pm, process <circularf...@gmail.comwrote:
> Quote: Quote:
I have heard some criticism about Python, that it is not fully object-
oriented.
> Quote: Quote:
That's not a bug, it's a feature ;-)
> Quote: Quote:
Why isn't len implemented as a str.len and list.len method insteadof
a len(list) function?
> Quote: Quote:
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)".
> Quote: Quote:
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).
> Quote:
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. Quote:
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 | | | | re: What is not objects in Python?
George Sakkis: Quote:
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 | | | | re: What is not objects in Python?
On Sep 29, 9:02 am, bearophileH...@lycos.com wrote: Quote:
George Sakkis:
> Quote:
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 ? Quote: Quote: Quote:
>>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'] Quote: Quote: Quote:
>>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: Quote: Quote: Quote:
>>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'] Quote: Quote: Quote:
>>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 | | | | re: What is not objects in Python?
George Sakkis wrote: Quote:
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. | | | | re: What is not objects in Python?
On Mon, 29 Sep 2008 11:14:36 -0400, Mel wrote: Quote:
George Sakkis wrote: Quote:
>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 | | | | re: What is not objects in Python?
George Sakkis: Quote:
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 | | | | re: What is not objects in Python?
On Sep 29, 11:37 am, bearophileH...@lycos.com wrote: Quote:
George Sakkis:
> Quote:
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 | | | | re: What is not objects in Python?
George Sakkis wrote: Quote:
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:
> Quote: Quote:
>>>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'] Quote: Quote:
>>>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 | | | | re: What is not objects in Python?
On Mon, 29 Sep 2008 05:41:02 -0700, George Sakkis wrote: Quote:
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 | | | | re: What is not objects in Python?
Steven D'Aprano wrote: Quote:
On Mon, 29 Sep 2008 05:41:02 -0700, George Sakkis wrote:
> Quote:
>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 | | | | re: What is not objects in Python?
On 28 set, 15:29, process <circularf...@gmail.comwrote: Quote:
I have heard some criticism about Python, that it is not fully object-
oriented.
So what? Quote:
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. | | | | re: What is not objects in Python?
In article <mailman.1716.1222747204.3487.python-list@python.org>,
Terry Reedy <tjreedy@udel.eduwrote: Quote:
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. | | | | re: What is not objects in Python?
On Mon, 29 Sep 2008 21:03:07 -0700, namekuseijin wrote: Quote: Quote:
>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 | | | | re: What is not objects in Python?
En Tue, 30 Sep 2008 01:03:07 -0300, namekuseijin <namekuseijin@gmail.com>
escribió: Quote:
On 28 set, 15:29, process <circularf...@gmail.comwrote:
Quote: Quote:
>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 | | | | re: What is not objects in Python?
Terry Reedy wrote: Quote:
Steven D'Aprano wrote: Quote:
>On Mon, 29 Sep 2008 05:41:02 -0700, George Sakkis wrote:
>> Quote:
>>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/ | | | | re: What is not objects in Python?
On Mon, 2008-09-29 at 21:03 -0700, namekuseijin wrote: Quote:
On 28 set, 15:29, process <circularf...@gmail.comwrote: Quote:
I have heard some criticism about Python, that it is not fully object-
oriented.
>
So what?
> Quote:
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?) | | | | re: What is not objects in Python?
Steven D'Aprano wrote: Quote:
On Mon, 29 Sep 2008 21:03:07 -0700, namekuseijin wrote:
> Quote: Quote:
>>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. Quote:
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/ | | | | re: What is not objects in Python?
Steven D'Aprano wrote: Quote:
On Mon, 29 Sep 2008 21:03:07 -0700, namekuseijin wrote:
> Quote: Quote:
>>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. Quote:
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/ | | | | re: What is not objects in Python?
En Tue, 30 Sep 2008 08:07:18 -0300, Steve Holden <steve@holdenweb.com>
escribió: Quote:
Terry Reedy wrote: Quote:
>Steven D'Aprano wrote:
Quote: Quote: Quote:
>>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 | | | | re: What is not objects in Python?
On Sep 30, 7:39*am, Steve Holden <st...@holdenweb.comwrote: Quote:
Steven D'Aprano wrote: Quote:
On Mon, 29 Sep 2008 21:03:07 -0700, namekuseijin wrote:
> Quote: Quote:
>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.
> > Quote:
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.
> Quote:
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? | | | | re: What is not objects in Python?
42, for instance.
Proof : Quote: Quote: Quote:
>>42 is not object
True
QED | | | | re: What is not objects in Python?
On Wed, 01 Oct 2008 17:56:34 +0200, Boris Borcic wrote: Quote:
42, for instance.
>
Proof :
> Quote: Quote:
>>42 is not object
True
>
QED
Quote: Quote: Quote:
>>isinstance(42, object)
True
--
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 -- pass it on | | | | re: What is not objects in Python?
Gabriel Genellina wrote: Quote:
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. | | | | re: What is not objects in Python?
Aaron "Castironpi" Brady wrote: Quote:
How do you have a yellow dog,
It's not a yellow dog, it's a dog yellow. Attention pay! :-)
--
Ewing Gregory | | | | re: What is not objects in Python?
On Fri, 03 Oct 2008 19:10:27 +1200, greg wrote: Quote:
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 | | | | re: What is not objects in Python?
Boris Borcic a écrit : Quote:
42, for instance.
>
Proof :
> Quote: Quote:
>>42 is not object
True
>
QED
>
Lol. | | | | re: What is not objects in Python?
2008/9/30 Lie Ryan <lie.1296@gmail.com>: Quote:
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 | | | | re: What is not objects in Python?
On Oct 3, 5:10*am, "Tim Rowe" <digi...@gmail.comwrote: Quote:
2008/9/30 Lie Ryan <lie.1...@gmail.com>:
> Quote:
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. | | | | re: What is not objects in Python?
... Unless, there is some corresponding distinction in mechanics Quote:
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). | | | | re: What is not objects in Python?
Marc 'BlackJack' Rintsch wrote: Quote:
On Fri, 03 Oct 2008 19:10:27 +1200, greg wrote:
Quote: Quote:
>>(BTW, try doing that with the x.len() notation!)
Quote:
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 |  |
| | |  /bytes/about
We are a network of experts and professionals in IT and software development that help one another with answers to tough questions and share insights.
Get the best answers to your questions from over 226,471 network members.
|
