Why does Python mix OO concepts and non OO concepts for operation s on basic types?
Michael Bauers
Why do you say x = []; x.append('a'), but get the length with len(a) ?
Is there a reason for this sort of inconsistency?
Jarno J Virtanen
>
> Why do you say x = []; x.append('a'), but get the length with len(a) ?
>
> Is there a reason for this sort of inconsistency?
why not check the FAQ?
David LeBlanc
I thought the reason for such built-in functions like len was from an early
point in Python's development when there where no classes?
Isn't there a move afoot to do away with most built-ins? I personally prefer
str.len() to len(str).
David LeBlanc
Seattle, WA USA
Syver Enstad
Yes, but the FAQ seems to be *very* old, it also says that in the
distant future it may be possible to subclass built in types.
I always have to back up in the editor when I am asking an object what
length it has. Like this (I wanna know the length of object foo):
foo. "Aw, It's not a method it's a function that calls a method with
an unsightly name behind the scenes" back the cursor up and write
len(foo) instead of foo.len() which would be much more intuitive.
--
Vennlig hilsen
Syver Enstad
A.Schmolck
Well, it has its advantages:
seq = ["one-two-three", "i ii iii", (1,2,3)]
maxLen = max(map(len, seq))
alex
Hans Nowak
>
> If item 6.6 in the FAQ is any indication, it's a bit out of date...
That seems indeed to be the case. Or it's Guido's time machine
gone awry... ;-)
> I thought the reason for such built-in functions like len was from an early
> point in Python's development when there where no classes?
Na, AFAIK Python has always had classes, even in ancient 0.9.1, the first
version posted to Usenet. I think the reason is/was, not every built-in
object had methods. (Tuples, strings, numbers, etc.) This has changed
in 2.2, although I don't know all the details; maybe there are
still such objects.
> Isn't there a move afoot to do away with most built-ins? I personally prefer
> str.len() to len(str).
The len() function doesn't bother me really... _some_ builtins will
hopefully always exists, or we'll have to write
(-3).__abs__()
Besides, while Python is object-oriented, that isn't the only
paradigm in the language. People coming from a functional
background may find the len() function more natural than a
method.
YMMV,
--
Hans (base64.decodestring('d3VybXlAZWFydGhsaW5rLm5ldA=='))
# decode for email address ;-)
The Pythonic Quarter:: http://www.awaretek.com/nowak/
Chris Liechti
news:u1yc3q...@online.no:
think abbout it as an operator. its is written in function syntax because
+-*/% etc are aleady used.
it has some advantages and it isn't "inconsistent" at all. i think you
do prefer to write
>>> 1 + 2
instead of
>>> 1 .__add__(2)
don't you?
(with or without underlines. apropos, "range(3).__len__()" works ;-)
of course you could also say that x[index] is not OO enough and insist on
having a .get(index) method (i.e. "[1,2,3].__getitem__(2)" now) but then
you could also take Java and type _much_ more for less readable code.
chris
--
Chris <clie...@gmx.net>
Michael P. Soulier
>
> think abbout it as an operator. its is written in function syntax because
> +-*/% etc are aleady used.
>
> it has some advantages and it isn't "inconsistent" at all. i think you
> do prefer to write
>>>> 1 + 2
> instead of
>>>> 1 .__add__(2)
> don't you?
> (with or without underlines. apropos, "range(3).__len__()" works ;-)
Actually, one of the few things I like about Ruby is that all objects in
Ruby do have methods, and thus to add two numbers...
2 + 4
2.+(4)
are equivalent.
Python _does_ seem mildly inconsistent in this regard. Giving strings
methods helped a bit, but tuples still have none, and neither do numbers.
>>> dir(())
[]
>>> dir(2)
[]
IMHO, they should all be objects with methods and a class, such that they
may be subclassed.
Mike
--
Michael P. Soulier <msou...@storm.ca>, GnuPG pub key: 5BC8BE08
"...the word HACK is used as a verb to indicate a massive amount
of nerd-like effort." -Harley Hahn, A Student's Guide to Unix
Terry Reedy
"Michael Bauers" <Mich...@firstlogic.com> wrote in message
news:mailman.102209128...@python.org...
>
> Why do you say x = []; x.append('a'), but get the length with len(a)
?
>
> Is there a reason for this sort of inconsistency?
In the beginning, there was a decision to make general multitype
functions/methods builtin functions instead of methods. Hence
type(object) instead of object.type(). For some types (strings and
tuples), this eliminated the need for methods. Before 2.2,
(1,2,3).len() was not possible.
Terry J. Reedy
Chris Liechti
news:ach7s6$c88$1...@news.storm.ca:
> On 23 May 2002 00:01:17 +0200, Chris Liechti <clie...@gmx.net> wrote:
>>
>> think abbout it as an operator. its is written in function syntax
>> because +-*/% etc are aleady used.
>>
>> it has some advantages and it isn't "inconsistent" at all. i think
>> you do prefer to write
>>>>> 1 + 2
>> instead of
>>>>> 1 .__add__(2)
>> don't you?
>> (with or without underlines. apropos, "range(3).__len__()" works ;-)
>
> Actually, one of the few things I like about Ruby is that all
> objects in
> Ruby do have methods, and thus to add two numbers...
>
> 2 + 4
> 2.+(4)
doesn't looks very readable to me, if thats realy calling the method
directly, not using the operator. at least i would expect that this is
adding the float 2.0 to an integer 4 which is in arithmetical braces which
just do nothing here. i.e. you can write that in python:
>>> 2.+(4)
6.0
the result is a float, but
>>> 2 .__add__(4)
6
(note the space betwen 2 and the dot) now its an integer result.
pythons way to write special methods with underlines "__add__" etc. makes
it very readble IMHO. and relaively easy to explain.
> are equivalent.
>
> Python _does_ seem mildly inconsistent in this regard. Giving
> strings
> methods helped a bit, but tuples still have none, and neither do
> numbers.
>
>>>> dir(())
> []
>>>> dir(2)
> []
well both have methods... "dir" is just not telling you everything you
expect. most methods belong to the class and not to the instance (you can
have such but they're rare). this means that the code for methods only
needs to be once in the memory and not mutiple times for each instance.
>>> dir(1 .__class__)
['__abs__', '__add__'...., '__xor__']
>>> len(dir(().__class__))
23
>>> (1,2,3).__getitem__(1)
2
> IMHO, they should all be objects with methods and a class, such
> that they may be subclassed.
they are, in 2.2+
chris
--
Chris <clie...@gmx.net>
Andrew Dalke
> Python _does_ seem mildly inconsistent in this regard. Giving strings
>methods helped a bit, but tuples still have none, and neither do numbers.
>
>>>> dir(())
>[]
>>>> dir(2)
>[]
>
> IMHO, they should all be objects with methods and a class, such that
they
>may be subclassed.
Upgrade to a newer version of Python. First, what 'dir' does was never
explicitly defined, and its implementation has since changed. Second,
one of the big changes in 2.2 was to make type subclassable.
>>> dir(2)
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
'__delattr
__', '__div__', '__divmod__', '__float__', '__floordiv__',
'__getattribute__', '__
hash__', '__hex__', '__init__', '__int__', '__invert__', '__long__',
'__lshift__',
'__mod__', '__mul__', '__neg__', '__new__', '__nonzero__', '__oct__',
'__or__', '
__pos__', '__pow__', '__radd__', '__rand__', '__rdiv__', '__rdivmod__',
'__reduce_
_', '__repr__', '__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__',
'__ror__',
'__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__',
'__rxor__',
'__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
>>> dir( () )
['__add__', '__class__', '__contains__', '__delattr__', '__eq__', '__ge__',
'__get
attribute__', '__getitem__', '__getslice__', '__gt__', '__hash__',
'__init__', '__
le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__',
'__repr_
_', '__rmul__', '__setattr__', '__str__']
>>>
Andrew
da...@dalkescientific.com
Greg Ewing
>
> Why do you say x = []; x.append('a'), but get the length with len(a) ?
>
> Is there a reason for this sort of inconsistency?
Something which hasn't been mentioned yet is that the
function-call style has some advantages when it comes
to adding new protocols to the language.
An example of this is the new iter() function. First
it looks to see if the object has an __iter__ method,
and if not, it falls back on older ways of iterating.
So, you can call iter() on any sequence object, old
or new, and it will do something sensible.
If the new protocol had been defined simply in
terms of a method, so that you said obj.iter()
instead of iter(obj), this would not have been
possible.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
Bernhard Herzog
> Before 2.2, (1,2,3).len() was not possible.
What does that have to do with 2.2? If the implementers had wanted it,
tuples could have methods in earlier versions as well.
Bernhard
--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
MapIt! http://www.mapit.de/
Quinn Dunkan
<msou...@mcss.mcmaster.ca_.nospam> wrote:
> Actually, one of the few things I like about Ruby is that all objects in
>Ruby do have methods, and thus to add two numbers...
>
> 2 + 4
> 2.+(4)
>
> are equivalent.
Not really:
irb(main):001:0> 1 + 2 * 3
7
irb(main):002:0> (1).+(2).*(3)
9
irb(main):003:0>
... and everyone was annoyed with smalltalk for being consistent that way :)
However, I don't think of 'obj.method' style notation as being the definition
of 'OO'. It's just a style of syntax. len(o) is just as 'OO' as o.len(), and
the real question is "why is the syntax different?".
One reasonable answer to that (besides history) is that f(x) and x.f() both
have different notational conveniences. It's nice to be able to type
map(len, lists) rather than [ a.len() for a in lists ], but it's also nice to
be able to type a.append(x) rather than list.append(a, x).
x.f() tends to be notationally handy where a closure on the first argument is
frequently useful (e.g. a.append). a.len is not so useful.
Steve Holden
I have updated this entry, and would welcome any feedback about the
changes -- it's just a first attempt, and I was trying not to be too
defensive about the inconsistencies. After all, history is important even in
technologies.
regards
Steve
--
-----------------------------------------------------------------------
Steve Holden http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/pwp/
-----------------------------------------------------------------------
James T. Dennis
> "Jarno J Virtanen" <jajv...@cc.helsinki.fi> wrote ...
>> Wed, 22 May 2002 13:13:06 -0500 Michael Bauers wrote:
>>> Why do you say x = []; x.append('a'), but get the length with len(a) ?
>>> Is there a reason for this sort of inconsistency?
>> why not check the FAQ?
>> http://www.python.org/cgi-bin/faqw.py?req=all#6.5
> I have updated this entry, and would welcome any feedback about the
> changes -- it's just a first attempt, and I was trying not to be too
> defensive about the inconsistencies. After all, history is important even in
> technologies.
> regards
> Steve
Personally I think it would be generally nice if I could
call most of the list and string methods in both ways:
list.append(somelist,someitem) would be the same as:
somelist.append(someitem).
And the obvious:
string.join('',something) would be as: ''.join(something).
(Personally I find the latter rendering to be ugly; a hobgoblin
of consistency).
Bjorn Pettersen
>
[snip]
>
> Personally I think it would be generally nice if I could
> call most of the list and string methods in both ways:
>
> list.append(somelist,someitem) would be the same as:
> somelist.append(someitem).
>
> And the obvious:
>
> string.join('',something) would be as: ''.join(something).
Your wish is granted:
>>> x = []
>>> list.append(x, 5)
>>> x
[5]
>>> str.join(' ', ['a', 'b', 'c'])
'a b c'
>>>
not-that-I-would-ever-do-something-like-that'ly y'rs
-- bjorn
James T. Dennis
>> From: James T. Dennis [mailto:jade...@idiom.com]
> >
> >>> x = []
> >>> list.append(x, 5)
> >>> x
> [5]
> >>> str.join(' ', ['a', 'b', 'c'])
> 'a b c'
> >>>
>
> not-that-I-would-ever-do-something-like-that'ly y'rs
> -- bjorn
Doh!
Thanks.
should-have-tried-that-before-I-posted'ly y'rs
Jim.
Don Garrett
> Besides, while Python is object-oriented, that isn't the only
> paradigm in the language. People coming from a functional
> background may find the len() function more natural than a
> method.
>
> YMMV,
>
That's one thing I don't get. Why wasn't len() added as a member to the
various types during the recent rework that added so many other members to the
native types?
--
Don Garrett http://www.bgb.cc/garrett/
BGB Consulting gar...@bgb.cc
holger krekel
> Hans Nowak wrote:
> > Besides, while Python is object-oriented, that isn't the only
> > paradigm in the language. People coming from a functional
> > background may find the len() function more natural than a
> > method.
> >
> > YMMV,
> >
>
> That's one thing I don't get. Why wasn't len() added as a member to the
> various types during the recent rework that added so many other members to the
> native types?
maybe duplicating '__len__' as 'len' is too much, well, duplication?
holger
holger krekel
> I only forgot how will I do this:
>
> map(string.split, s)
>
> if GvR will deprecate string module...
what about
map(str.split, s)
:-) holger
Roman Suzi
>Hans Nowak wrote:
>> Besides, while Python is object-oriented, that isn't the only
>> paradigm in the language. People coming from a functional
>> background may find the len() function more natural than a
>> method.
>>
>> YMMV,
>>
>
> That's one thing I don't get. Why wasn't len() added as a member to the
>various types during the recent rework that added so many other members to the
>native types?
...and what for do we need all those funny slices,
attribute assignments, ..?
a.set(b, c)
print a.get(b)
a.set_b(c)
is much nicer than:
a[b] = c
print a[b]
a.b = c
I also wonder why to contaminate a wonderful language with
all those <, >, &, |, ..., +, - ? Look, how nice these examples are:
a.add(b.multiply(c))
instead of ugly, Perlish, unOOPish:
a + b * c
...
I only forgot how will I do this:
map(string.split, s)
if GvR will deprecate string module...
Sincerely yours, Roman Suzi
--
\_ Russia \_ Karelia \_ Petrozavodsk \_ r...@onego.ru \_
\_ Tuesday, June 11, 2002 \_ Powered by Linux RedHat 7.2 \_
\_ "I can't use Windows. The cat ate my mouse." \_
Ville Vainio
> I only forgot how will I do this:
>
> map(string.split, s)
>
> if GvR will deprecate string module...
List comprehension is as pretty IMO.
At least it will be if/when the iteration variable (or whatever) will
no longer be visible after the list comprehension.
Name it ____listcomp_____var, like in class private vars, and del it
after running the comprehension?
-- Ville
John La Rooy
what about
map(string.capwords, s)
I'm guessing it's an oversight that there is no str.capwords??
John ;oP
holger krekel
probably. With python 1.6 many methods of the string *module* were
included included directly with the *type* string ('str'). Most
python developers think that the string module should be deprecated
some time in the future. But there are some issues which haven't been
resolved so far. 'capwords' is one of them IMO and not very difficult.
the 'string' module might even be never deprecated because so many
programs (including more than 20 stdlib-modules) use it.
holger