Rick Johnson wrote:
> On Sunday, February 10, 2013 5:29:54 AM UTC-6, Steven D'Aprano wrote:
>> Rick wrote:
>> And you have missed my point, which is that reversed(), and sorted(),
>> were not added to the language on a whim, but because they were
>> requested, over and over and over again.
>
> Well, well, this explains everything!
>
> We don't add features because of logic, or because of consistency, or even
> because of good sense, we simply add them to appease the masses.
They were requested because people kept re-inventing them. They kept
re-inventing them because they are useful functions that make good sense to
have.
>> "appended" is called list addition.
>>
>> newlist = oldlist + [item_to_append]
>
> But where is the consistency?
Strings use + for concatenation. Tuples use + for concatenation. Lists use +
for concatenation. Seems pretty consistent to me.
Are you sure you've used Python before?
> Yes the syntactic sugar of the "plus sign" is concise, however, the "+"
> operator does not "pair" intuitively with the "append" method.
Adding "ed" to a word does not pair intuitively with the method name. You
have to learn it, which in the case of most English speakers you probably
did between the ages of 2 and 6.
Using + to represent concatenation is no less intuitive.
> Even IF you
> transformed the "+" operator into a named method like "add" (or call the
> magic method "__add__") it still fails to mesh properly with "append", and
> the two words utterly fail to intuitively establish an "in-place" versus
> "copy-mutate" relationship.
So what?
>> > flatten, flattened
>>
>> flatten is another often requested, hard to implement correctly,
>> function. The only reason that Python doesn't have a flatten is that
>> nobody can agree on precisely what it should do.
>
> Steven, the definition of flatten (as relates to sequences) is very, VERY
> simple:
>
> Return a new sequence that is the result of reducing
> a nested sequence of sequences into a single depth
> sequence.
Very, VERY simple until you actually implement this function, and discover
that it does too much e.g.
flatten([None, 23, [1, 2, 3], Point(x=2, y=3), ["spam", "ham"]])
=> [None, 23, 1, 2, 3, 2, 3, 's', 'p', 'a', 'm', 'h', 'a', 'm']
So people who have *actually programmed*, instead of just talking about
programming, have discovered that in practice you need to treat some
sequences as primitives that don't get expanded.
>> Like map, filter, reduce, etc. flatten is not sensibly implemented as a
>> mutator method, but as a function.
>
> Only because you, along with a few other high ranking members of this
> community (including the BDFL himself!) have this /aversion/ to true OOP
> paradigm.
>
> Can you provide an example of how flatten "as a method" is incorrect
> versus flatten "as a function" is correct, or will this challenge be
> silently swept under the rug as so many before?
Simple efficiency. The most efficient, and sensible, way to flatten a list
is to create a new list. Trying to flatten a list in place is a dumb
idea -- it is O(n**2), or possibly even worse. Since only an idiot would
write flatten as an in-place method, any mutator version of flatten would
have to use a non-mutator version, then use slicing to over-write itself:
def flatten(self):
new_list = flatten(self)
self[:] = new_list
which is fine if you absolutely have to have an in-place version, but why
bother? The caller can do it themselves:
mylist = flatten(mylist)
[snip]
>> > map, mapped
>> > filter, filtered
>> > reduce, reduced
>>
>> Those are nonsense. None of those are in-place mutator methods.
>
> Well not in the current implementation of Python; but they could be if we
> wanted them to be.
Now you're smoking crack. How can *reduce* be an in-place mutator method?
py> mylist = [1, 2, 3, 4, 5]
py> from operator import mul
py> reduce(mul, mylist)
120
I would really like to see your implementation of a reduce method that turns
a list into an int *in-place*.
> Applying mutations both "in-place" and "to a copy" are
> very helpful.
Exactly.
[snip]
>> > My point was this: All mutate methods should mutate "in-place",
>>
>> Well duh. All mutator methods do mutate in-place, otherwise they wouldn't
>> be mutator methods.
>
> So "reversed()" and "sorted()" mutate in-place?
No. They are not mutator methods, because they do not mutate in place.
>> > if the
>> > programmer wishes to create a mutated copy of the object, then the
>> > programmer should /explicitly/ create a copy of the object and then
>> > apply the correct mutator method to the copy.
>>
>> Been there, done that, it sucks. That's about a dozen steps backwards to
>> a worse time in Python development.
>
> Why? Because you have to type this
>
> reversed = list(seq).reverse()
Are you sure you've programmed in Python before? That gives reversed = None.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
