Fredrik Lundh wrote:
> "Bryan" wrote:
>
>>> and how do you make sure that everything subclasses this base class ?
>> in this hypothetical case, i was assuming len() would be put in object and
>> every
>> class subclasses object implicitly or explicitly (ie, new style classes
>> only).
>> if it w
> >>> isinstance(1, object)
> True
>
> What's 1 . len() ?
That's easy!
since 1 is actually syntactic sugar for set([set([])]), clearly 1.len()
== 1.
;-)
v.
(actually, make that frozenset([frozenset([])])...)
--
http://mail.python.org/mailman/listinfo/python-list
Bryan wrote:
> Fredrik Lundh wrote:
>
>>Bryan wrote:
>>
>>
>>>could you get the same result by putting these methods in base
>>
>> > class object that everything subclasses?
>>
>>and how do you make sure that everything subclasses this base class ?
>>
>>
>>
>
> in this hypothetical case, i was as
"Bryan" wrote:
>> and how do you make sure that everything subclasses this base class ?
>
> in this hypothetical case, i was assuming len() would be put in object and
> every
> class subclasses object implicitly or explicitly (ie, new style classes only).
> if it was done that way, would len(obj)
Fredrik Lundh wrote:
> Bryan wrote:
>
>> could you get the same result by putting these methods in base
> > class object that everything subclasses?
>
> and how do you make sure that everything subclasses this base class ?
>
>
>
in this hypothetical case, i was assuming len() would be put in
Terry Reedy wrote:
> "OKB (not okblacke)" <[EMAIL PROTECTED]> wrote in message
[...]
>
> The underlying answer to the original question is that while Pyt;hon is
> object-based, it is not strictly OO but is intentionally multiparadigmatic
> and will remain so. For instance, no one will be force
Paul Rubin wrote:
> Steven Bethard <[EMAIL PROTECTED]> writes:
>> If len() were a method of string objects, you could try using the
>> unbound method and writing this as::
>>
>> >>> sorted(['aaa', 'bb', 'c'], key=str.len)
>> ['c', 'bb', 'aaa']
>>
>> But then your code would break on lists
Bryan wrote:
> Steven Bethard wrote:
>
>> The advantage of a functional form over a method shows up when you
>> write a function that works on a variety of different types. Below are
>> implementations of "list()", "sorted()" and "join()" that work on any
>> iterable and only need to be defined
Bryan wrote:
> could you get the same result by putting these methods in base
> class object that everything subclasses?
and how do you make sure that everything subclasses this base class ?
--
http://mail.python.org/mailman/listinfo/python-list
Steven Bethard a écrit :
> The advantage of a functional form over a method shows up when you write
> a function that works on a variety of different types. Below are
> implementations of "list()", "sorted()" and "join()" that work on any
> iterable and only need to be defined once::
>
> [... skip
Piet van Oostrum wrote:
>>Bruno Desthuilliers <[EMAIL PROTECTED]> (BD) wrote:
>
>
>>BD> Actually, and AFAIK, len(obj) = lambda obj : obj.__len__().
>
>
> You mean: len = lambda obj : obj.__len__().
yes, of course - not enough caffein, I guess...
Thanks
--
bruno desthuilliers
python -c "p
> Bruno Desthuilliers <[EMAIL PROTECTED]> (BD) wrote:
>BD> Actually, and AFAIK, len(obj) = lambda obj : obj.__len__().
You mean: len = lambda obj : obj.__len__().
--
Piet van Oostrum <[EMAIL PROTECTED]>
URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4]
Private email: [EMAIL PROTECTED]
--
>- why is len() not a member function of strings? Instead one says len(w).
Coming from a Java background, I also thought this a weird setup.
However IMHO there is another good reason to have len(obj) as we do in
Python: it helps to enforce some sort of uniformity across code.
If I want to fi
"guthrie" wrote:
> But if (as I proposed..!) the user interface is better if presented as a
> method. one could porovide convenience methods which would then
> interface to these underlying library functions; yes?
but if it isn't? and why this obsession with superficial syntax details?
there's
guthrie wrote:
> Good point, thanks.
>
> But if (as I proposed..!) the user interface is better if presented as a
> method. one could porovide convenience methods which would then
> interface to these underlying library functions; yes?
>
Actually, and AFAIK, len(obj) = lambda obj : obj.__len__().
Steven Bethard <[EMAIL PROTECTED]> writes:
> If len() were a method of string objects, you could try using the
> unbound method and writing this as::
>
> >>> sorted(['aaa', 'bb', 'c'], key=str.len)
> ['c', 'bb', 'aaa']
>
> But then your code would break on lists that weren't strings.
s
Steven Bethard wrote:
> Terry Reedy wrote:
>
>> "Gregory Guthrie" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>
>>> - why is len() not a member function of strings? Instead one says
>>> len(w).
>>
>>
>> Consider
>>
> map(len, ('abc', (1,2,3), [1,2], {1:2}))
>>
>> [3, 3, 2
Alex Martelli wrote:
> Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>...
>
>>>This would allow things like:
>>>key = '',join( list(word.lower().strip()).sort() )
>>
>>key = ''.join(list(sorted(word.lower().strip()))
>
>
> No need to make yet another list here (also, I think eac
Steven Bethard wrote:
> The advantage of a functional form over a method shows up when you write
> a function that works on a variety of different types. Below are
> implementations of "list()", "sorted()" and "join()" that work on any
> iterable and only need to be defined once::
>
> def
Good point, thanks.
But if (as I proposed..!) the user interface is better if presented as a
method. one could porovide convenience methods which would then
interface to these underlying library functions; yes?
So the main datatype classes could support such a method style, and just
layer on t
Many thanks; great information.
Best,
Gregory
Steven Bethard wrote:
> guthrie wrote:
>
>> Steven Bethard wrote:
>>
>>> Why would ``x.len()`` be any more convenient than ``len(x)``? Your
>>> preference here seems pretty arbitrary.
>>
>> -- Perhaps;
>> but having all standard operations as a m
Terry Reedy wrote:
> "Gregory Guthrie" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> - why is len() not a member function of strings? Instead one says
>> len(w).
>
> Consider
map(len, ('abc', (1,2,3), [1,2], {1:2}))
> [3, 3, 2, 1]
>
> Now try to rewrite this using meth
guthrie wrote:
> Steven Bethard wrote:
>> Why would ``x.len()`` be any more convenient than ``len(x)``? Your
>> preference here seems pretty arbitrary.
> -- Perhaps;
> but having all standard operations as a method seems more regular (to
> me), and allows a simple chained operation format of a se
"OKB (not okblacke)" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>
>> Consider
> map(len, ('abc', (1,2,3), [1,2], {1:2}))
>> [3, 3, 2, 1]
>>
>> Now try to rewrite this using methods (member functions).
>
> [a.len() for a in ('abc', (1,2,3), [1,2], {1:2})]
Steven Bethard wrote:
> Gregory Guthrie wrote:
>
>> For example,
>>- why is len() not a member function of strings? Instead one says
>> len(w).
>
> Why would ``x.len()`` be any more convenient than ``len(x)``? Your
> preference here seems pretty arbitrary.
-- Perhaps;
but having all standa
Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
...
> > This would allow things like:
> > key = '',join( list(word.lower().strip()).sort() )
>
> key = ''.join(list(sorted(word.lower().strip()))
No need to make yet another list here (also, I think each of you omitted
a needed closed-
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> Length is an obvious property of any one-dimensional non-scalar, not just
> strings. As such, it makes sense to have a length function that takes an
> argument. As a design decision, it could go either way, but early
> Python wasn't fully object-oriente
Steven D'Aprano <[EMAIL PROTECTED]> writes:
> >> Now try to rewrite this using methods (member functions).
> > [a.len() for a in ('abc', (1,2,3), [1,2], {1:2})]
>
> Did you actually try that?
No of course not. It's in a hypothetical python where .len() is a
class operation instead of a global fu
Steven D'Aprano wrote:
> On Sun, 09 Jul 2006 22:45:53 +, OKB (not okblacke) wrote:
>
>> Terry Reedy wrote:
>>
>>> Consider
>> map(len, ('abc', (1,2,3), [1,2], {1:2}))
>>> [3, 3, 2, 1]
>>>
>>> Now try to rewrite this using methods (member functions).
>> [a.len() for a in ('abc', (1,2,3), [
On Sun, 09 Jul 2006 22:45:53 +, OKB (not okblacke) wrote:
> Terry Reedy wrote:
>
>> Consider
> map(len, ('abc', (1,2,3), [1,2], {1:2}))
>> [3, 3, 2, 1]
>>
>> Now try to rewrite this using methods (member functions).
>
> [a.len() for a in ('abc', (1,2,3), [1,2], {1:2})]
Did you actually
On Sun, 09 Jul 2006 12:19:13 -0500, Gregory Guthrie wrote:
> I am comparing Python to a few other scripting languages, and used a simple
> anagrams program as a sample.
>
> I was surprised ast a few python features that did not work as I would
> expect/wish; which caused less compact/expressive
"Terry Reedy" <[EMAIL PROTECTED]> writes:
> Consider
> >>> map(len, ('abc', (1,2,3), [1,2], {1:2}))
> [3, 3, 2, 1]
>
> Now try to rewrite this using methods (member functions).
[x.len() for x in ('abc', (1,2,3), [1,2], {1:2})]
> > - Why doesn't sort() return a value?
>
> Because it is an in-pl
Terry Reedy wrote:
> Consider
map(len, ('abc', (1,2,3), [1,2], {1:2}))
> [3, 3, 2, 1]
>
> Now try to rewrite this using methods (member functions).
[a.len() for a in ('abc', (1,2,3), [1,2], {1:2})]
--
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead. Go, inste
"Gregory Guthrie" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> - why is len() not a member function of strings? Instead one says
> len(w).
Consider
>>> map(len, ('abc', (1,2,3), [1,2], {1:2}))
[3, 3, 2, 1]
Now try to rewrite this using methods (member functions).
> - Why d
Gregory Guthrie wrote:
> I am comparing Python to a few other scripting languages, and used a simple
> anagrams program as a sample.
>
> I was surprised ast a few python features that did not work as I would
> expect/wish; which caused less compact/expressive program styles that I
> wanted - rever
Gregory Guthrie a écrit :
> I am comparing Python to a few other scripting languages, and used a simple
> anagrams program as a sample.
>
> I was surprised ast a few python features that did not work as I would
> expect/wish; which caused less compact/expressive program styles that I
> wanted -
Gregory Guthrie wrote:
> For example,
>- why is len() not a member function of strings? Instead one says len(w).
Why would ``x.len()`` be any more convenient than ``len(x)``? Your
preference here seems pretty arbitrary.
> - Why doesn't sort() return a value?
>
> This would allow thing
37 matches
Mail list logo
