proposals for having more fun with map

[Alex Martelli]

Tom Anderson <twic at urchin.earth.li> wrote:
   ...
> details = {
>       "surnname": "Cleese",
>       "firstname": "John",
>       "dob": 19391027,
>       "birthplace": "Weston-super-Mare",
>       "height: 1.95,
>       "favourite work": "the documentary about lemurs"
> }
> template = ("firstname", "surname", "height")
> info = map(details, template)

Use map(details.get, template) and you can get this today.  No reason to
change dicts for this purpose.

> okay, so maybe you're not convinced, but this is something i find myself
> wanting to do all the time, so i either end up throwing lambdas all over
> the place to glue the dicts into map, or writing a little helper function
> like so:
> 
> def functor(dict):
>       return lambda arg: dict[arg]
> 
> this isn't hard, of course, but it's the sort of thing that ought to be
> done once and only once.

It is -- you simply need the bound method somedict.get (in 2.4 it might
be slightly faster to call somedict.__getitem__, I think in 2.3
somedict.get is faster and in any case it _is_ nicer to type!-).


> however, i do wonder if sequences could have a keys method, which would
> look like:
> 
> def keys(self):
>       return range(len(self))
> 
> so they look like mappings of a range of the natural numbers. the problem
> with that is that the sequence and mapping versions of __iter__ are
> incompatible. oh well.

Yep, not worth doing.


> secondly, map should work on dicts as well as sequences. map has semantics
> that look like this:
> 
> map(fn, x)[i] = fn(x[i])
> 
> at the moment, x has to be a sequence; i'd like to allow x to be a
> mapping. the implementation is a doddle:

Nope, a dict is accepted as x today:

>>> d=dict(a=23,b=42,c=69)
>>> map(lambda x:x, d)
['a', 'c', 'b']
>>> 

This cannot be changed w/o backwards incompatibilities (so, propose it
for Python 3000 -- won't get in before then, as it would break some
current, perfectly correct programs).


> anyway, that's it. am i bonkers, or does any of that sound like a good
> idea?

Why should the two be mutually incompatible?-)

Seriously: some of your ideas may have merit but you should realize no
changes that break currently working programs are gonna get in until 3.0
at the earliest, and even in 3.0 the focus will be on simplification.
If you're keep on your backwards-incompatible proposals you might be
luckier with some of the various python-like languages which are
springing up _without_ the backwards compatibility requirements of
Python, such as bobo or Prothon.  For Python itself, you must deal with
the additional burden of backwards compatibility on top of everything...


Alex