[Yum-devel] [PATCH] Deprecate has_key() in favour of "in" for metadata entries.

[Ville Skyttä]

On Thursday 08 October 2009, Ville Skyttä wrote:
> On Thursday 08 October 2009, James Antill wrote:
> > On Thu, 2009-10-08 at 00:11 +0300, Ville Skyttä wrote:
> > > On Friday 02 October 2009, Ville Skyttä wrote:
> > > > Hello,
> > > >
> > > > As someone mentioned Python 3 here and on fedora-devel... here's a
> > > > small patch that gets metadata entries' has_key() out of the way of
> > > > further has_key() related changes.
> > > >
> > > > So when previously one would do "entry.has_key(foo)", after this one
> > > > should do "foo in entry" instead.
> > >
> > > Any comments?
> >
> >  We know we have to do this eventually, as the giant py3k suckage moves
> > towards us. I'm not sure we want to do it before 3.2.25 is released
> > though ... and we should really do a lot of it at once (see: git grep
> > has_key).
> 
> Yes, that's pretty much the whole point of this patch: it gets the only
> instance of has_key() that can't be trivially changed to "in" or something
> else out of the way so the rest can be safely grepped and done at once.  I
> have patches taking care of that as well, and I plan to start submitting
>  them once this is in.

Now that 3.2.25 is out, could I get some more comments about this patch (e.g. 
good to go in, or should be abandoned until it's time to address all has_key 
things, ...)?