On Thu, 2005-06-30 at 13:37, Raymond Hettinger wrote: > > If there are no objections, I propose to do the following (only in > > Python 2.4 and 2.5): > > > > * Add set.union_update() as an alias for set.update(). > > No. It was intentional to drop the duplicate method with the > hard-to-use name. There was some thought given to deprecating > sets.union_update() but that would have just caused unnecessary grief.
Oh, okay. Did you run out of clever abbreviations after s/union_update/update/ or do you think that symmetric_difference_update is already easy enough to use? ;) Why was "update" chosen when you have two other forms of longer *_update() methods on sets? This is after all, a union and it's arguably more confusing not to have that in the name (especially given the "easy-to-use" other *_update() methods). > > I consider this a bug in 2.4, not a new feature, because without it, > it > > makes more work in porting applications. > > Bah. It's just one of the handful of search/replace steps: > > Set --> set > ImmutableSet --> frozenset > union_update --> update But an unnecessary one, IMO. > > I'm willing to Just Fix It, > > Please don't. All of the differences between set and Set were > intentional improvements (i.e. the hash algorithm's are different). I don't care about the implementation, I'm sure it's vastly superior. I'm concerned with the API. I don't agree that dropping union_update() is necessarily an improvement, but I guess I had my chance when the PEP was being debated, so I'll drop it. I do think you owe it to users to describe the differences in PLR $2.3.7 to aid people in the transition process. -Barry
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
