2.2.2 Annoyance

J

Jegenye 2001 Bt

Caveat:

Python 2.2.2 (#37, Oct 14 2002, 17:02:34)
Type "help", "copyright", "credits" or "l
l = [1,2,3]
l[1] 2
l.__getitem__(1) 2
l.__getitem__(slice(1))
Traceback (most recent call last):

According to the manuals of Python 2.2.2, passing a slice object to
__getitem__ is all right and should work...
Cost a few (grey) hairs of mine, while debugging a largish program, this is
not so.
Would someone care to pass on this info to whom this may concern?

For Python 2.3 passing a slice object to __getitem__ does work though.

Best,
Miklós
 
T

Terry Reedy

Jegenye 2001 Bt said:
According to the manuals of Python 2.2.2, passing a slice object to ....
Would someone care to pass on this info to whom this may concern?

2.2.2 was superceded by 2.2.3. This info is only of concern to people
who have and will not upgrade to 2.3.
For Python 2.3 passing a slice object to __getitem__ does work
though.

2.3 fixed more bugs beyond 2.2.3, added a couple of builtins, and
several modules. This change in behavior between 2.2.2 and 2.3 was
almost certainly intentional, due someone already noticing what you
did.

tjr
 
J

Jegenye 2001 Bt

Terry Reedy said:
2.2.2 was superceded by 2.2.3. This info is only of concern to people
who have and will not upgrade to 2.3.

I hadn't known about 2.2.3* and 2.3 was/is (?) out at that site for the time
being.

* thanx, I will try it .. even though I have already patched the code by
'try/except's

Miklós
 
M

Michael Hudson

Jegenye 2001 Bt said:
Caveat:

Python 2.2.2 (#37, Oct 14 2002, 17:02:34)
Type "help", "copyright", "credits" or "l
l = [1,2,3]
l[1] 2
l.__getitem__(1) 2
l.__getitem__(slice(1))
Traceback (most recent call last):

According to the manuals of Python 2.2.2, passing a slice object to
__getitem__ is all right and should work...

Really? Where does it say that?
For Python 2.3 passing a slice object to __getitem__ does work though.

Yes. Do you have a good reason for sticking to 2.2?

Cheers,
mwh
 
M

Miklós

Michael Hudson said:
Really? Where does it say that?

Python Reference Manual,
3.3.4 Emulating container types
(Release 2.2.2, documentation updated on October 14, 2002. )
"""
__getitem__(self, key)
Called to implement evaluation of self[key]. For sequence types, the
accepted keys should be integers and slice objects. Note that the special
interpretation of
"""
Yes. Do you have a good reason for sticking to 2.2?
Yes, see my previous post on this. (That site wants to stay with 2.2 for the
time being.)

Actually I patched the code to circumvent this and I haven't tried 2.2.3 as
for this yet. (I didn't know about 2.2.3 until Terry's response..)

All this is no big deal ... unless you pull too many hairs of your receding
head because of a bug like this. :))

Cheers,
Miklós
 
M

Michael Hudson

Miklós said:
Michael Hudson said:
Really? Where does it say that?

Python Reference Manual,
3.3.4 Emulating container types
(Release 2.2.2, documentation updated on October 14, 2002. )
"""
__getitem__(self, key)
Called to implement evaluation of self[key]. For sequence types, the
accepted keys should be integers and slice objects. Note that the special
interpretation of
"""

I think this is talking about implementing __getitem__, not calling it
directly. Historically these things have been quite different, though
they are becoming less so.
Yes, see my previous post on this.

I haven't had the time to read all posts to this ng for some time...
(That site wants to stay with 2.2 for the time being.)
OK.

Actually I patched the code to circumvent this and I haven't tried 2.2.3 as
for this yet. (I didn't know about 2.2.3 until Terry's response..)

2.2.3 will not make any difference on this point.

Cheers,
mwh
 
M

Miklós

Michael Hudson said:
Miklós said:
"""
__getitem__(self, key)
Called to implement evaluation of self[key]. For sequence types, the
accepted keys should be integers and slice objects. Note that the special
interpretation of
"""

I think this is talking about implementing __getitem__, not calling it
directly. Historically these things have been quite different, though
they are becoming less so.
Well, I've never been really into the guts of Python ... but could you shed
some light for me on that why these two things are different?
What I experienced was this "feature" broke my code (actually it was in a
3rd party code library) and it took a while for me to recognize the
documentation was wrong
(or whatever, depending on your explanation..) and slice objects shouldn't
be passed to __getitem__ that way in Python 2.2
(and that this works for Python 2.3)
2.2.3 will not make any difference on this point.

Well, then my patches will stay and slow down things a bit.


Cheers,
Miklós
 
M

Michael Hudson

Miklós said:
Michael Hudson said:
Miklós said:
"""
__getitem__(self, key)
Called to implement evaluation of self[key]. For sequence types, the
accepted keys should be integers and slice objects. Note that the special
interpretation of
"""

I think this is talking about implementing __getitem__, not calling it
directly. Historically these things have been quite different, though
they are becoming less so.
Well, I've never been really into the guts of Python ... but could you shed
some light for me on that why these two things are different?

Hmm, that's potentially a large topic. I'll have a go.

At the C implementation level, Python distinguishes sequences (lists,
strings, tuples, arrays, etc) and mappings (dicts, basically).
However, Python-the-language uses the same notation -- brackets, [] --
to access the elements of both sequences and mappings, and there's
only one corresponding special method -- __getitem__.

If you're implementing a sequence in C, you're expected to fill out
the tp_as_sequence structure of the type object, which contains these
fields:

typedef struct {
inquiry sq_length;
binaryfunc sq_concat;
intargfunc sq_repeat;
intargfunc sq_item;
intintargfunc sq_slice;
intobjargproc sq_ass_item;
intintobjargproc sq_ass_slice;
objobjproc sq_contains;
/* Added in release 2.0 */
binaryfunc sq_inplace_concat;
intargfunc sq_inplace_repeat;
} PySequenceMethods;

Notice that "sq_item" -- the function that retrieves an element of the
sequence -- is an "intargfunc", which is:

typedef PyObject *(*intargfunc)(PyObject *, int);

and "sq_slice" is an "intintargfunc", i.e:

typedef PyObject *(*intintargfunc)(PyObject *, int, int);

So, there's no way to actually implement a sequence that directly
handles a slice object! You have to make a mapping instead (the
corresponding function in PyMappingMethods is mp_subscript, a
binaryfunc:

typedef PyObject * (*binaryfunc)(PyObject *, PyObject *);

). This is the first reason you can't pass slice objects to
list.__getitem__ in 2.2 -- list just didn't implement mp_subscript.

The other reason is: just what is "list.__getitem__"? If list was
implemented in Python, it would be obvious, it would be an unbound
method. But list *isn't* implementing in Python, list is implemented
in C, so list.__getitem__ is a thing called a method-wrapper. When
you access it, magic happens to find the appropriate C level method
and wrap it up so you can call it from Python. But for __getitem__
specifically, there are two choices, sq_item and mp_subscript! 2.2
prefers sq_item, so even after the list type grew a mp_subscript
function [1].__getitem__(slice(0,1)) failed, because the
method-wrapper for sq_item didn't know what to do with the slice
object. 2.3 prefers mp_subscript over sq_item.

Hope that helped!

Cheers,
mwh
 
M

Miklós

[long explanation deleted]

Huh, that was really tough reading for an un-C-er..
Still I think I savvy the thing: there was a semantic change at the
underlying C implementation level.

I understand the rationale for deprecating '__getslice__' from v2.0
onwards was to make sequences and mappings to look more
alike. But then this change for __getitem__ should have been absolutely
introduced at that time or the semantics of CPython between 2.0 and 2.2
doesn't make sense in this respect... Am I right in that?
Hope that helped!

Yes, I think so. :) Many thanks.


Best,
Miklós
--
Jegenye 2001 Bt.
'amVnZW55ZTIwMDFAcGFya2hvc3RpbmcuY29t\n'.decode('base64')
Egyedi szoftverkészítés, tanácsadás
Custom software development, consulting
http://jegenye2001.parkhosting.com
 
M

Michael Hudson

Miklós said:
I understand the rationale for deprecating '__getslice__' from v2.0
onwards was to make sequences and mappings to look more alike. But
then this change for __getitem__ should have been absolutely
introduced at that time or the semantics of CPython between 2.0 and
2.2 doesn't make sense in this respect... Am I right in that?

Well, sort of. Back in the 2.0 days you couldn't even write:

was right out! It's all a bit messy, and it's sorted out in 2.3.

Cheers,
mwh
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,020
Latest member
GenesisGai

Latest Threads

Top