Re: [Python-Dev] Inconsistent API for sets.Set and build-in set
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
[Python-Dev] Inconsistent API for sets.Set and build-in set
I've been looking at the API for sets.Set and built-in set objects in Python 2.4.1 and I think I have found some minor inconsistencies. Background: we have an object that is very similar to sets and we originally modeled the API after sets.Set since we started with Python 2.3. Now I'm trying to update the API so that it's consistent with Python 2.4's built-in set object and I've noticed the following discrepancies. set.Set has both an .update() method and a .union_update() method. They appear to be completely identical, accepting either a Set object or an arbitrary sequence. This is the case despite the docstring difference for these two methods and the fact that Set.update() isn't documented on the texinfo page. Built-in set has only .update() though but it acts just like the set.Set methods above. Note that of all these methods, only Set.update() is documented to take an iterable argument. These inconsistencies could prove a bit problematic when porting Py2.3 applications using sets.Set to Py2.4 using built-in set. I'd like to fix this for Python 2.4.2, and I think the changes are pretty minimal. 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(). * Add to docstrings for all methods that 't' can be any iterable. * Update texinfo documentation to add Set.update() and set.union_update() and explain that all can take iterables I consider this a bug in 2.4, not a new feature, because without it, it makes more work in porting applications. Thoughts? I'm willing to Just Fix It, but if someone wants to see a patch first, I'll be happy to generate it and post it to SF. -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
Re: [Python-Dev] Inconsistent API for sets.Set and build-in set
On Thu, Jun 30, 2005, Barry Warsaw 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(). * Add to docstrings for all methods that 't' can be any iterable. * Update texinfo documentation to add Set.update() and set.union_update() and explain that all can take iterables I consider this a bug in 2.4, not a new feature, because without it, it makes more work in porting applications. +0 (I'm only not +1 because I don't use sets much -- I'm still mired in Python 2.2 -- but I'm always happy to see inconsistencies resolved) I'll guess that Raymond will probably want 2.5 to have set.union_update() get a PendingDeprecationWarning. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ f u cn rd ths, u cn gt a gd jb n nx prgrmmng. ___ 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
Re: [Python-Dev] Inconsistent API for sets.Set and build-in set
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. * Add to docstrings for all methods that 't' can be any iterable. * Update texinfo documentation to add Set.update() and set.union_update() and explain that all can take iterables Feel free to assign a doc patch to me. 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 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). Raymond ___ 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
