2.2.2 Annoyance

Discussion in 'Python' started by Jegenye 2001 Bt, Nov 22, 2003.

  1. 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):
    File "<stdin>", line 1, in ?
    TypeError: an integer is required
    >>>


    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
     
    Jegenye 2001 Bt, Nov 22, 2003
    #1
    1. Advertising

  2. Jegenye 2001 Bt

    Terry Reedy Guest

    "Jegenye 2001 Bt" <> wrote in message
    news:bpoo6c$nhh$...
    > 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
     
    Terry Reedy, Nov 23, 2003
    #2
    1. Advertising

  3. Terry Reedy <> wrote in message
    news:...
    >
    > "Jegenye 2001 Bt" <> wrote in message
    > news:bpoo6c$nhh$...
    > > 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.
    >


    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

    > tjr
    >
    >
     
    Jegenye 2001 Bt, Nov 23, 2003
    #3
  4. "Jegenye 2001 Bt" <> writes:

    > 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):
    > File "<stdin>", line 1, in ?
    > TypeError: an integer is required
    > >>>

    >
    > 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

    --
    Python enjoys making tradeoffs that drive *someone* crazy <wink>.
    -- Tim Peters, comp.lang.python
     
    Michael Hudson, Nov 24, 2003
    #4
  5. Jegenye 2001 Bt

    Miklós Guest

    Michael Hudson <> wrote in message
    news:...
    > "Jegenye 2001 Bt" <> writes:
    >
    > > 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?


    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
    """

    >
    > > 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?
    >

    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

    > Cheers,
    > mwh
    >
    > --
    > Python enjoys making tradeoffs that drive *someone* crazy <wink>.
    > -- Tim Peters, comp.lang.python
     
    Miklós, Nov 24, 2003
    #5
  6. "Miklós" <> writes:

    > Michael Hudson <> wrote in message
    > news:...
    > > "Jegenye 2001 Bt" <> writes:
    > >
    > > > 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?

    >
    > 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.

    > > > 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?
    > >

    > 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

    --
    ARTHUR: Don't ask me how it works or I'll start to whimper.
    -- The Hitch-Hikers Guide to the Galaxy, Episode 11
     
    Michael Hudson, Nov 24, 2003
    #6
  7. Jegenye 2001 Bt

    Miklós Guest

    Michael Hudson <> wrote in message
    news:...
    > "Miklós" <> writes:
    >
    > > """
    > > __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


    >
    > Cheers,
    > mwh
    >
    > --
    > ARTHUR: Don't ask me how it works or I'll start to whimper.
    > -- The Hitch-Hikers Guide to the Galaxy, Episode 11
     
    Miklós, Nov 24, 2003
    #7
  8. "Miklós" <> writes:

    > Michael Hudson <> wrote in message
    > news:...
    > > "Miklós" <> writes:
    > >
    > > > """
    > > > __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

    --
    The "of course, while I have no problem with this at all, it's
    surely too much for a lesser being" flavor of argument always
    rings hollow to me. -- Tim Peters, 29 Apr 1998
     
    Michael Hudson, Nov 25, 2003
    #8
  9. Jegenye 2001 Bt

    Miklós Guest

    Michael Hudson <> wrote in message
    news:...
    > "Miklós" <> writes:
    >
    >

    [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


    > Cheers,
    > mwh
    >
     
    Miklós, Nov 25, 2003
    #9
  10. "Miklós" <> writes:

    > 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:

    >>> [].__getitem__


    so

    >>> [].__getitem__(slice(0,1))


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

    Cheers,
    mwh

    --
    Monte Carlo sampling is no way to understand code.
    -- Gordon McMillan, comp.lang.python
     
    Michael Hudson, Nov 26, 2003
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. PL
    Replies:
    0
    Views:
    2,647
  2. Replies:
    0
    Views:
    309
  3. Chris

    JavaHelp annoyance

    Chris, Apr 6, 2006, in forum: Java
    Replies:
    1
    Views:
    374
    Bjorn Abelli
    Apr 6, 2006
  4. rf

    annoyance question

    rf, Nov 16, 2003, in forum: HTML
    Replies:
    27
    Views:
    766
  5. David Baxter

    Javascript / IE6 Annoyance

    David Baxter, Apr 8, 2005, in forum: HTML
    Replies:
    2
    Views:
    497
    Csaba Gabor
    Apr 9, 2005
Loading...

Share This Page