From: dhruvbird on
On Jul 12, 5:30 am, News123 <news1...(a)free.fr> wrote:
> dhruvbird wrote:
>
> > On a side note, is there any other way to append to a list using
> > slices (apart from the one below):
> > x[len(x):len(x)] = [item to append]
>
> dy you mean
> x.extend([1,2,3])

No, I meant x.append(4)
Except that I want to accomplish it using slices.

(I can do it as x[lex(x):] = [item_to_append] but is there any other
way?)

Regards,
-Dhruv.
From: Hrvoje Niksic on
dhruvbird <dhruvbird(a)gmail.com> writes:

> No, I meant x.append(4)
> Except that I want to accomplish it using slices.
>
> (I can do it as x[lex(x):] = [item_to_append] but is there any other
> way?)

It seems that you've found a way to do so, so why do you need another
way? Are you after elegance? Efficiency? Brevity?

Here are some other ways to express the same, and all use slices in some
way:

x[slice(len(x), None)] = [item_to_append]
x.__setitem__(slice(len(x), None), [item_to_append])
x.__setslice__(len(x), len(x), [item_to_append])

....but I have no idea why any of them would make any more sense than
x[len(x):] = [item_to_append].
From: dhruvbird on
On Jul 12, 4:20 pm, Hrvoje Niksic <hnik...(a)xemacs.org> wrote:
> dhruvbird <dhruvb...(a)gmail.com> writes:
> > No, I meant x.append(4)
> > Except that I want to accomplish it using slices.
>
> > (I can do it as x[lex(x):] = [item_to_append] but is there any other
> > way?)
>
> It seems that you've found a way to do so, so why do you need another
> way?  Are you after elegance?  Efficiency?  Brevity?

Actually, the reason I ask is because I think a lot of things can be
done using slices and its support for negative indexes. Basically
putting constants in the slices (as opposed to variables like len(x),
etc... which depend upon the variable name). So, was just trying to
cogitate on whether append can be implemented that way or not.

Regards,
-Dhruv.
From: John Nagle on
On 7/11/2010 5:24 PM, Steven D'Aprano wrote:
> On Sun, 11 Jul 2010 08:59:06 -0700, dhruvbird wrote:
>
>> Why doesn't python's list append() method return the list itself? For
>> that matter, even the reverse() and sort() methods? I found this link
>> (http://code.google.com/edu/languages/google-python- class/lists.html)
>> which suggests that this is done to make sure that the programmer
>> understands that the list is being modified in place, but that rules out
>> constructs like:
>> ([1,2,3,4].reverse()+[[]]).reverse()
>
> Yes. So what? Where's the problem?
>
> List methods work in place.
....
> Not everything needs to be a one-liner.

It's interesting that all Python functions are considered to
return a value. Arguably, if a function just does a "return",
it should be an error to try to use its return value.

Some languages have a very functional orientation, and
everything is considered to return some value, even
control structures. LISP is like that. But Python isn't
one of those languages.

John Nagle

From: Gregory Ewing on
John Nagle wrote:
> Arguably, if a function just does a "return",
> it should be an error to try to use its return value.

It's been suggested at least once before that the
default return value for a function should be some
special value that raises an exception if you try
to do anything with it except throw it away.

Unfortunately, the existence of such a value would
cause headaches for things like debuggers that need
to be able to deal with anything at all without
blowing up.

--
Greg