sets

[Gerrit Holl]

Brett C. wrote:

Sets now at blazing C speeds!
-----------------------------
Raymond Hettinger implemented the sets API in C! The new built-ins are
set (which replaces sets.Set) and frozenset (which replaces
sets.ImmutableSet). The APIs are the same as the sets module sans the
name change from ImmutableSet to frozenset.

Contributing threads:
- `set() and frozenset()
<http://mail.python.org/pipermail/python-dev/2003-November/040253.html>`__

Will the sets module now be deprecated?
Or will they stay and be re-implemented so they become like UserDict,
UserList, UserString?

yours,
Gerrit.

--
147. If she have not borne him children, then her mistress may sell her
for money.
-- 1780 BC, Hammurabi, Code of Law
--
Asperger's Syndrome - a personal approach:
http://people.nl.linux.org/~gerrit/english/

[Raymond Hettinger]

> Brett C. wrote:

Sets now at blazing C speeds!
-----------------------------
Raymond Hettinger implemented the sets API in C! The new built-ins are
set (which replaces sets.Set) and frozenset (which replaces
sets.ImmutableSet). The APIs are the same as the sets module sans the
name change from ImmutableSet to frozenset.

"Gerrit Holl" Will the sets module now be deprecated?
No, sets.py will be left alone so that existing code continues to run. Also,
sets.py continues to have value for anyone needing its autoconversion feature
that was not included for set(). Also, sets.py was made compatible with
Py2.2, so it can be shipped with code that needs to run on older pythons.

Or will they stay and be re-implemented so they become like UserDict,
UserList, UserString?

Do not expect more additions to the User**** series, the need for them was
almost completely subsumed by the ability to subclass a builtin type. One could
envision a SetMixin; however, performance considerations will be a strong force
towards always using real sets.
Raymond Hettinger