NewBuiltins: added dict() -- inverse of dict.items() 
Author Message
 NewBuiltins: added dict() -- inverse of dict.items()

I thought some of you find it interesting: I did a silent
update to my mxTools (aka NewBuiltins) package and added a
function many have probably been already looking for:

dict(items)
         Constructs a dictionary from the given items sequence. The
         sequence must contain sequence entries with at least two
         values. The first one is interpreted as key, the second one
         as associated object. Remaining values are ignored.

--
Marc-Andre Lemburg                      
......................................................................
            |  Python Pages:   http://www.*-*-*.com/ ~lemburg/  |
             --------------------------------------------------------



Sun, 03 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

That sounds good!

Why do you allow for more than 2 entries in the tuples? I
wouldn't for clarity, and according to Aaron's initializers
8see below).

How about an optional parameter "inverse" which defaults to 0,
which makes the behavior the other way round, giving an inverse
mapping?

I would use it like this:

def inversedict(dict) :
        return mxTools.dict(dict.items(), 1)

I'm not sure wether the dict function should raise an exception
if duplicates on the left (or right for inverse!=0) occour or not.
Maybe not, when I think of dict.update() .

You might also have a look into Aaron's incredible kjbuckets module.
Your dict() function would be great there, since it makes it very
easy to transit between kjbuckets objects and ordinary dictionaries.
BTW., using the inverse operator on kjDicts, I could get my "inverse"
without extending your "dict":

def inversedict(dict) :
     aarons = kjbuckets.kjDict(dict.items())
     return mxTools.dict(~aarons)

As Guido pointed out lately, the mentioned modules are not so likely
to become standard modules. On the other hand, there are a lot of
modules in the distribution which have special purposes. Why don't we
pack some very useful, however specialized modules into an extra
package which is distributed as "expert extensions" or something?

cheers - pirx

Quote:

> I thought some of you find it interesting: I did a silent
> update to my mxTools (aka NewBuiltins) package and added a
> function many have probably been already looking for:

> dict(items)
>          Constructs a dictionary from the given items sequence. The
>          sequence must contain sequence entries with at least two
>          values. The first one is interpreted as key, the second one
>          as associated object. Remaining values are ignored.

> --
> Marc-Andre Lemburg
> ......................................................................
>             |  Python Pages:  http://starship.skyport.net/~lemburg/  |
>              --------------------------------------------------------

--

Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.skyport.net
10553 Berlin                 :     PGP key -> http://pgpkeys.mit.edu
     we're tired of banana software - shipped green, ripens at home


Mon, 04 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

Evening all,

Just wanted to ask whether this function might become standard?  It's _so_
common a thing to want to do (well, for me anyway :) ), and it's there and...
oh... oh... _please Guido_ ;)

I suppose an "expert" distribution's okay, but really this does seem like
something that's needed in the base distribution.  Though if it's
possible/practical, making it a method on a dictionary (just like update, maybe
even by overloading update) might help to keep the builtin namespace clear.

$0.02 please, :) ,
Mike

... (Quoted by Christian)

Quote:

...
>> dict(items)
>>          Constructs a dictionary from the given items sequence. The
>>          sequence must contain sequence entries with at least two
>>          values. The first one is interpreted as key, the second one
>>          as associated object. Remaining values are ignored.

________________________________
 M i k e   C .  F l e t c h e r


http://www.golden.net/~mcfletch/
________________________________
 Design, Consultation, Training



Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

Quote:

> That sounds good!

> Why do you allow for more than 2 entries in the tuples? I
> wouldn't for clarity, and according to Aaron's initializers
> 8see below).

Well, it probably shouldn't and raise an exception in case it sees
anything with more entries... maybe I'll change that for the next
release.

Quote:
> How about an optional parameter "inverse" which defaults to 0,
> which makes the behavior the other way round, giving an inverse
> mapping?

> I would use it like this:

> def inversedict(dict) :
>         return mxTools.dict(dict.items(), 1)

> I'm not sure wether the dict function should raise an exception
> if duplicates on the left (or right for inverse!=0) occour or not.
> Maybe not, when I think of dict.update() .

What exactly do you have in mind here ? Something like:

dict(((key,value),...)) == { value:key, ... } ?

Seems like a job for a reverse(sequence) function, e.g. one that returns
a list (or tuple) with the sequence's entries in reverse order.

Then a simple dict(map(reverse,myitems)) would do the trick.

Note that dict() does not raise an exception if it overwrites
entries with the same key. It behaves much like dict.update()
in this respect. Should it rather raise an exception ?

Quote:
> You might also have a look into Aaron's incredible kjbuckets module.
> Your dict() function would be great there, since it makes it very
> easy to transit between kjbuckets objects and ordinary dictionaries.
> BTW., using the inverse operator on kjDicts, I could get my "inverse"
> without extending your "dict":

> def inversedict(dict) :
>      aarons = kjbuckets.kjDict(dict.items())
>      return mxTools.dict(~aarons)

> As Guido pointed out lately, the mentioned modules are not so likely
> to become standard modules. On the other hand, there are a lot of
> modules in the distribution which have special purposes. Why don't we
> pack some very useful, however specialized modules into an extra
> package which is distributed as "expert extensions" or something?

You mean a whole library with extensions ? Great idea. But also
difficult to administer, e.g. I'm pushing out new versions of my
stuff quite frequently.

I think what people are most interested in are prebuilt binaries
(especially the WinXX folks since their OS doesn't ship a compiler).

--
Marc-Andre Lemburg                      
......................................................................
            |  Python Pages:  http://starship.skyport.net/~lemburg/  |
             --------------------------------------------------------



Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

...

Quote:
> > I would use it like this:

> > def inversedict(dict) :
> >         return mxTools.dict(dict.items(), 1)

> > I'm not sure wether the dict function should raise an exception
> > if duplicates on the left (or right for inverse!=0) occour or not.
> > Maybe not, when I think of dict.update() .

> What exactly do you have in mind here ? Something like:

> dict(((key,value),...)) == { value:key, ... } ?

> Seems like a job for a reverse(sequence) function, e.g. one that returns
> a list (or tuple) with the sequence's entries in reverse order.

Exactly.

Quote:
> Then a simple dict(map(reverse,myitems)) would do the trick.

Right. See the example with kjBuckets which has all this.
Except for a way to go back to "ordinary" dicts, which your func
does now.

Quote:
> Note that dict() does not raise an exception if it overwrites
> entries with the same key. It behaves much like dict.update()
> in this respect. Should it rather raise an exception ?

No, it is, like update(), nothing more than a time saver for a simple
python loop which also would not raise an exception. It is easier to
think that way.

Quote:
> > You might also have a look into Aaron's incredible kjbuckets module.
> > Your dict() function would be great there, since it makes it very
> > easy to transit between kjbuckets objects and ordinary dictionaries.
> > BTW., using the inverse operator on kjDicts, I could get my "inverse"
> > without extending your "dict":

> > def inversedict(dict) :
> >      aarons = kjbuckets.kjDict(dict.items())
> >      return mxTools.dict(~aarons)

> > As Guido pointed out lately, the mentioned modules are not so likely
> > to become standard modules. On the other hand, there are a lot of
> > modules in the distribution which have special purposes. Why don't we
> > pack some very useful, however specialized modules into an extra
> > package which is distributed as "expert extensions" or something?

> You mean a whole library with extensions ? Great idea. But also
> difficult to administer, e.g. I'm pushing out new versions of my
> stuff quite frequently.

That is one of the reasons why I thing we could use that library.
I want to move some function off of single persons into something
like a group which takes care about some special extensions. In
fact these would be the authors of the parts of the package.
But the package would be distributed as a whole, and changes would
be discussed with the contributors.
They would rely on the functionality of their code, partially.

This would move us away from "my extensions" and "your extensions"
towards something which is useful as a whole, free of repetitions,
and more consistent.

The target would be to get this included into the distribution,
in a sense of "useful stuff for experts" which should not be
documented like standard modules, but have its extra place.

Quote:
> I think what people are most interested in are prebuilt binaries
> (especially the WinXX folks since their OS doesn't ship a compiler).

And of course this package would be precompiled. Think of the
PythonWin extensions. I want such a thing as another addition.

--

Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.skyport.net
10553 Berlin                 :     PGP key -> http://pgpkeys.mit.edu
     we're tired of banana software - shipped green, ripens at home



Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

Quote:

> > You mean a whole library with extensions ? Great idea. But also
> > difficult to administer, e.g. I'm pushing out new versions of my
> > stuff quite frequently.

> That is one of the reasons why I thing we could use that library.
> I want to move some function off of single persons into something
> like a group which takes care about some special extensions. In
> fact these would be the authors of the parts of the package.
> But the package would be distributed as a whole, and changes would
> be discussed with the contributors.
> They would rely on the functionality of their code, partially.

We could set up a tiny mailing list for this on starship.

Quote:
> This would move us away from "my extensions" and "your extensions"
> towards something which is useful as a whole, free of repetitions,
> and more consistent.

Good idea. The new package mechanism should make this easy
and if all authors agree on using Makefile.pre.in as compilation
motor, then even the setup should be manageable.

Quote:

> The target would be to get this included into the distribution,
> in a sense of "useful stuff for experts" which should not be
> documented like standard modules, but have its extra place.

> > I think what people are most interested in are prebuilt binaries
> > (especially the WinXX folks since their OS doesn't ship a compiler).

> And of course this package would be precompiled. Think of the
> PythonWin extensions. I want such a thing as another addition.

Only question is: we need enough volunteers, both authors and
people willing to compile the lib on their platform, to
make this idea work...

--
Marc-Andre Lemburg                      
......................................................................
            |  Python Pages:  http://starship.skyport.net/~lemburg/  |
             --------------------------------------------------------



Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

Quote:
M.-A. Lemburg writes:
>Good idea. The new package mechanism should make this easy
>and if all authors agree on using Makefile.pre.in as compilation
>motor, then even the setup should be manageable.

        One suggestion might be to add an "extensions" target to the
top-level Makefile that would go into the Extensions subdirectory, and
then run a make in any subdirectories.  That way, new packages could
simply be unpacked into Extensions/ and automatically picked.  Once
it's stable, "make all" could be changed to automatically trigger the
"extensions" target, and "make install" do the same.  

        IMHO putting things in Extensions/ is much better than just
dumping every new extension module into Modules and editing Setup
accordingly; it permits more automation, and also makes it easier to
upgrade to a new version of Python without losing additions to the
Modules/ directory (speaking as someone who's just lost a module that
way).  You'd only have to copy over the Extensions/ tree.

A.M. Kuchling                   http://starship.skyport.net/crew/amk/
Every man makes his own summer. The season has no character of its own, unless
one is a farmer with a professional concern for the weather.
        -- Robertson Davies, "Three Worlds, Three Summers--- But Not the
           Summer Just Past"



Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

Quote:
> Only question is: we need enough volunteers, both authors and
> people willing to compile the lib on their platform, to
> make this idea work...

I'll compile anything anyone wants as long as you send me reasonable C/C++
code, and a Setup file which works on Unix.  It'll allow me to test my
automagic script.  I'll send back Win32 .pyd files and 'upgraded' Setup
files.

--david



Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

I'm happy that this little idea has so much response.
I am going to set up a mailing list. How about

Or should we better give BSCW a try in this case?

ciao - pirx

Quote:

> M.-A. Lemburg writes:
> >Good idea. The new package mechanism should make this easy
> >and if all authors agree on using Makefile.pre.in as compilation
> >motor, then even the setup should be manageable.

>         One suggestion might be to add an "extensions" target to the
> top-level Makefile that would go into the Extensions subdirectory, and
> then run a make in any subdirectories.  That way, new packages could
> simply be unpacked into Extensions/ and automatically picked.  Once
> it's stable, "make all" could be changed to automatically trigger the
> "extensions" target, and "make install" do the same.

>         IMHO putting things in Extensions/ is much better than just
> dumping every new extension module into Modules and editing Setup
> accordingly; it permits more automation, and also makes it easier to
> upgrade to a new version of Python without losing additions to the
> Modules/ directory (speaking as someone who's just lost a module that
> way).  You'd only have to copy over the Extensions/ tree.

--

Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.skyport.net
10553 Berlin                 :     PGP key -> http://pgpkeys.mit.edu
     we're tired of banana software - shipped green, ripens at home


Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

For discussing and organizing the project

Python Expert Library


The list is not moderated, and subscriptions are auto-approved by
now. Admins are currently me and Marc Lemburg. This can be changed
at any time, just to start with something which is not None.

Please subscribe via the HTML interface at
http://starship.skyport.net/mailman/admin/expert-lib

ciao - pirx

--

Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101   :    *Starship* http://starship.skyport.net
10553 Berlin                 :     PGP key -> http://pgpkeys.mit.edu
     we're tired of banana software - shipped green, ripens at home



Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

Quote:

> For discussing and organizing the project

> Python Expert Library


> The list is not moderated, and subscriptions are auto-approved by
> now. Admins are currently me and Marc Lemburg. This can be changed
> at any time, just to start with something which is not None.

> Please subscribe via the HTML interface at
> http://starship.skyport.net/mailman/admin/expert-lib

I think Christian meant to give this URL:
http://starship.skyport.net/mailman/listinfo/expert-lib

--
Robin Dunn

http://starship.skyport.net/crew/robind

Need a laugh?  Try http://starship.skyport.net/crew/robind/laughworks



Tue, 05 Sep 2000 03:00:00 GMT  
 NewBuiltins: added dict() -- inverse of dict.items()

Quote:

> > Only question is: we need enough volunteers, both authors and
> > people willing to compile the lib on their platform, to
> > make this idea work...

> I'll compile anything anyone wants as long as you send me reasonable C/C++
> code, and a Setup file which works on Unix.  It'll allow me to test my
> automagic script.  I'll send back Win32 .pyd files and 'upgraded' Setup
> files.

Great. So Makefile.pre.in/Setup will even be usable on WinXX
platforms...
that's nice to hear.

Will there also be a similar too for the Macintosh ? Jack ?

--
Marc-Andre Lemburg                      
......................................................................
            |  Python Pages:  http://starship.skyport.net/~lemburg/  |
             --------------------------------------------------------



Wed, 06 Sep 2000 03:00:00 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. expanding a list and dict to a *args and **dict

2. Dict can't update with dict-like objects

3. Builtin dict should be callable, since a dict defines a funct ion

4. Builtin dict should be callable, since a dict defines a function

5. Dict to String and String to Dict with Visual Works

6. Iterating over the data items in a dict.

7. Iterating order of dict.items()

8. Tcl8.5: [string map $dict ...] and ordering inside $dict

9. Dict. to String and String to Dict. with Visual Works

10. Edit in place and dict rules

11. Recreating a Btreive Dict

12. Importing MS SQL table into Clarion Dict.

 

 
Powered by phpBB® Forum Software