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