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

Re: [Python-Dev] operator.itemgetter with a callback method

On Sun, Jan 11, 2009 at 2:02 PM, Alexandre Fiori fio...@gmail.com 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

Re: [Python-Dev] operator.itemgetter with a callback method

thanks! On Sun, Jan 11, 2009 at 2:12 PM, Guilherme Polo ggp...@gmail.com wrote: On Sun, Jan 11, 2009 at 2:02 PM, Alexandre Fiori fio...@gmail.com wrote: hello i was thinking about a possible improvement for the itemgetter the documentation page shows simple examples like sorting a

[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

[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

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

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,

Re: [Python-Dev] __long__ method still exists in Python 3.x

On Sun, Jan 11, 2009 at 12:40 PM, Martin v. Löwis mar...@v.loewis.de 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