[Python-Dev] operator.itemgetter with a callback method
hello
i was thinking about a possible improvement for the itemgetter
the documentation page shows simple examples like sorting a dictionary by
its integer values, like this:
>>> inventory = [('apple', 3), ('banana', 2), ('pear', 5), ('orange', 1)]
>>> getcount = itemgetter(1)
>>> map(getcount, inventory)
[3, 2, 5, 1]
>>> sorted(inventory, key=getcount)
[('orange', 1), ('banana', 2), ('apple', 3), ('pear', 5)]
let's suppose i have dictionary where items are lists (instead of integers),
and i want to sort it by the size of each list:
>>> friends = {
... 'alex': ['bob', 'jane'],
... 'mary': ['steve', 'linda', 'foo bar'],
... 'john': ['max']
... }
>>> sorted(friends.items(), key=itemgetter(1))
[('alex', ['bob', 'jane']), ('john', ['max']), ('mary', ['steve', 'linda',
'foo bar'])]
that doesn't work since itemgetter(1) will return a list, and that's not
useful for sorting.
i didn't look at the code, but i suppose itemgetter is something like this:
class itemgetter:
def __init__(self, index):
self.index = index
def __call__(self, item):
return tem[self.index]
in order for that sort (and possibly a lot of other things) to work
properly, we could add
a callback method for itemgetter, like this:
class itemgetter:
def __init__(self, index, callback=None):
self.index = index
self.callback = callback
def __call__(self, item):
return self.callback and self.callback(item[self.index]) or
item[self.index]
so, we could easly sort by the amount of data in each list, like this:
>>> sorted(friends.items(), key=itemgetter(1, callback=len))
[('john', ['max']), ('alex', ['bob', 'jane']), ('foo', ['bar', 'steve',
'linda'])]
what do you guys think about it? please correct me if i'm wrong.
--
Ship ahoy! Hast seen the While Whale?
- Melville's Captain Ahab
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator.itemgetter with a callback method
On Sun, Jan 11, 2009 at 2:02 PM, Alexandre Fiori wrote:
>
> hello
>
> i was thinking about a possible improvement for the itemgetter
> the documentation page shows simple examples like sorting a dictionary by
> its integer values
Hi,
Sorry for starting like this but ideas are supposed to be emailed to
the python-ideas maillist.
> .
> .
>
> in order for that sort (and possibly a lot of other things) to work
> properly, we could add
> a callback method for itemgetter, like this:
>
> class itemgetter:
> def __init__(self, index, callback=None):
> self.index = index
> self.callback = callback
>
> def __call__(self, item):
> return self.callback and self.callback(item[self.index]) or
> item[self.index]
>
> so, we could easly sort by the amount of data in each list, like this:
>
sorted(friends.items(), key=itemgetter(1, callback=len))
> [('john', ['max']), ('alex', ['bob', 'jane']), ('foo', ['bar', 'steve',
> 'linda'])]
>
>
> what do you guys think about it? please correct me if i'm wrong.
>
>
You are not forced to use itemgetter as a key in sorted, you can
provide your own key method, like this:
def x(item):
return len(item[1])
sorted(friends.items(), key=x)
Also, your idea ruins the name "itemgetter" since it is no longer a itemgetter.
--
-- Guilherme H. Polo Goncalves
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] operator.itemgetter with a callback method
thanks!
On Sun, Jan 11, 2009 at 2:12 PM, Guilherme Polo wrote:
> On Sun, Jan 11, 2009 at 2:02 PM, Alexandre Fiori wrote:
> >
> > hello
> >
> > i was thinking about a possible improvement for the itemgetter
> > the documentation page shows simple examples like sorting a dictionary by
> > its integer values
>
> Hi,
>
> Sorry for starting like this but ideas are supposed to be emailed to
> the python-ideas maillist.
>
> > .
> > .
> >
> > in order for that sort (and possibly a lot of other things) to work
> > properly, we could add
> > a callback method for itemgetter, like this:
> >
> > class itemgetter:
> > def __init__(self, index, callback=None):
> > self.index = index
> > self.callback = callback
> >
> > def __call__(self, item):
> > return self.callback and self.callback(item[self.index]) or
> > item[self.index]
> >
> > so, we could easly sort by the amount of data in each list, like this:
> >
> sorted(friends.items(), key=itemgetter(1, callback=len))
> > [('john', ['max']), ('alex', ['bob', 'jane']), ('foo', ['bar', 'steve',
> > 'linda'])]
> >
> >
> > what do you guys think about it? please correct me if i'm wrong.
> >
> >
>
> You are not forced to use itemgetter as a key in sorted, you can
> provide your own key method, like this:
>
> def x(item):
>return len(item[1])
>
> sorted(friends.items(), key=x)
>
> Also, your idea ruins the name "itemgetter" since it is no longer a
> itemgetter.
>
> --
> -- Guilherme H. Polo Goncalves
>
--
Ship ahoy! Hast seen the While Whale?
- Melville's Captain Ahab
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] How should I handle unsupported features?
Hi! Porting to MS Windows CE, I find that e.g. signals or environment vars are not supported. How should I handle that? In particular, I'm talking about PyOS_getsig() and PyOS_setsig(). Should I just #ifdef them out completely or should I implement them by setting an error? Which error should I set? cheers Uli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __long__ method still exists in Python 3.x
I noticed that the builtin numeric types (int, float, complex) all still have a __long__ method in 3.x. Shouldn't this have disappeared as part of the int/long unification? Is there any reason not to remove this (by setting the nb_long entry to 0 in all three cases)? Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How should I handle unsupported features?
> Porting to MS Windows CE, I find that e.g. signals or environment vars are > not > supported. How should I handle that? So that scripts that try to make use of these features operate in a reasonable way. > In particular, I'm talking about > PyOS_getsig() and PyOS_setsig(). Should I just #ifdef them out completely or > should I implement them by setting an error? Which error should I set? My proposal would be to actually implement signal handlers for CE. Try to minimize the amount of code change that you need to perform (*). Not sure what exactly that means, but probably, you need to provide at least the symbolic constants mandated by C. E.g. define NSIG, SIG_IGN, SIG_DFL, SIGINT, and perhaps a few others the same way the the VS9 CRT defines them, then implement PyOS_setsig so that it operates on an array of NSIG function pointers. None of the signal handlers will ever be called - which essentially means that the signals just don't arise. Alternatively, if you regret the storage for the signal handlers, you might a) make some or all of the signals not supported; signal(2) is defined to return SIG_ERR in that case, and set errno to EINVAL. Not sure what will break if Python can't even successfully set a SIGINT handler. b) cheat on setsig, not actually recording the signal handler. Not sure whether any code relies on getsig(k, setsig(k, f)) == f Regards, Martin (*) This is a general advise. If some feature is not supported on a minority platform, it would be a pity if a lot of code needs to be written to work around. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __long__ method still exists in Python 3.x
> I noticed that the builtin numeric types (int, float, complex) all still > have a __long__ method in 3.x. Shouldn't this have disappeared as > part of the int/long unification? Is there any reason not to remove this > (by setting the nb_long entry to 0 in all three cases)? There are, apparently, still callers of the nb_long slot, so I would be cautious. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __long__ method still exists in Python 3.x
On Sun, Jan 11, 2009 at 12:40 PM, "Martin v. Löwis" wrote: >> I noticed that the builtin numeric types (int, float, complex) all still >> have a __long__ method in 3.x. Shouldn't this have disappeared as >> part of the int/long unification? Is there any reason not to remove this >> (by setting the nb_long entry to 0 in all three cases)? > > There are, apparently, still callers of the nb_long slot, so I would be > cautious. We should remove all usage of it and rename it to nb_reserved. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
