getitem with slices??

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

getitem with slices??

Dexter-24
Hi, 

So they're re-factoring python a bit, some backwards (incompatible) changes to fix certain inconsistencies. 
And I also knew that some other inconsistencies aren't gonna be changed, because of backwards incompatibility. 
But I didn't know that they were also introducing inconsistencies, which is also breaking backwards compatibility.

getslice is being depricated, if you wanna use that, you should use getitem in p3k. So now, you should check if your argument is an index or a slice. 
Can anyone explain why?

Greetings, Dexter

_______________________________________________
Python-nl mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-nl
Reply | Threaded
Open this post in threaded view
|

Re: getitem with slices??

Pepijn de Vos-2
No explanation, but this is one aspect of "pythonic" that has been bothering me of late.

The general consensus is that you should use duck typing, and in general not have items of a different type in one place.

So the "pythonic" solution would be to have getslice, I would think, but if that is not available, the "pythonic" thing to do is something like:

try:
    foo.slicy_thing()
except TypeError:
    foo.number_thing()

IMO, exceptions are for exceptional occasions, not for disguised if statements. But, that's the way Python seems to work.

Pepijn

On Apr 19, 2012, at 4:10 PM, Dexter wrote:

> Hi,
>
> So they're re-factoring python a bit, some backwards (incompatible) changes to fix certain inconsistencies.
> And I also knew that some other inconsistencies aren't gonna be changed, because of backwards incompatibility.
> But I didn't know that they were also introducing inconsistencies, which is also breaking backwards compatibility.
>
> getslice is being depricated, if you wanna use that, you should use getitem in p3k. So now, you should check if your argument is an index or a slice.
> Can anyone explain why?
>
> Greetings, Dexter
> _______________________________________________
> Python-nl mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/python-nl

_______________________________________________
Python-nl mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-nl
Reply | Threaded
Open this post in threaded view
|

Re: getitem with slices??

Ronald Oussoren
In reply to this post by Dexter-24

On 19 Apr, 2012, at 16:10, Dexter wrote:

> Hi,
>
> So they're re-factoring python a bit, some backwards (incompatible) changes to fix certain inconsistencies.
> And I also knew that some other inconsistencies aren't gonna be changed, because of backwards incompatibility.
> But I didn't know that they were also introducing inconsistencies, which is also breaking backwards compatibility.
>
> getslice is being depricated, if you wanna use that, you should use getitem in p3k. So now, you should check if your argument is an index or a slice.
> Can anyone explain why?

__getslice__ doesn't support extended slicing (obj[start:stop:step])

Ronald


_______________________________________________
Python-nl mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-nl

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: getitem with slices??

Dexter-24
I've noticed, but it just seems like they are trying to do multiple things with one function, which doesn't look like to be in the zen of python. .
I'd reckon they should've supported extended slicing with the __getslice__ method.


On Thu, Apr 19, 2012 at 5:10 PM, Ronald Oussoren <[hidden email]> wrote:

On 19 Apr, 2012, at 16:10, Dexter wrote:

> Hi,
>
> So they're re-factoring python a bit, some backwards (incompatible) changes to fix certain inconsistencies.
> And I also knew that some other inconsistencies aren't gonna be changed, because of backwards incompatibility.
> But I didn't know that they were also introducing inconsistencies, which is also breaking backwards compatibility.
>
> getslice is being depricated, if you wanna use that, you should use getitem in p3k. So now, you should check if your argument is an index or a slice.
> Can anyone explain why?

__getslice__ doesn't support extended slicing (obj[start:stop:step])

Ronald


_______________________________________________
Python-nl mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-nl



_______________________________________________
Python-nl mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-nl
Reply | Threaded
Open this post in threaded view
|

Re: getitem with slices??

Dirkjan Ochtman
In reply to this post by Pepijn de Vos-2
On Thu, Apr 19, 2012 at 16:51, Pepijn de Vos <[hidden email]> wrote:

> No explanation, but this is one aspect of "pythonic" that has been bothering me of late.
>
> The general consensus is that you should use duck typing, and in general not have items of a different type in one place.
>
> So the "pythonic" solution would be to have getslice, I would think, but if that is not available, the "pythonic" thing to do is something like:
>
> try:
>    foo.slicy_thing()
> except TypeError:
>    foo.number_thing()
>
> IMO, exceptions are for exceptional occasions, not for disguised if statements. But, that's the way Python seems to work.

I'm not sure what you're getting at here, but I'm pretty sure having
an isinstance() call here and there is perfectly Pythonic. Look Before
You Leap has its place, just like Easier to Ask Forgiveness than
Permission.

I googled and annotated the source a bit and found mailing list
threads from when it was deprecated, but there was no clear rationale.
Still, it's been deprecated a long time, this happened in July 2000,
so the feeling that this is something recent isn't really justified.

Also, since __getitem__() could just as easily return a sequence as a
single item, it seems like there isn't really much point to having
separate things for this, and I find the solution with passing slice()
objects to __getitem__() quite elegant.

Cheers,

Dirkjan
_______________________________________________
Python-nl mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-nl