On Mon, Nov 29, 2010 at 2:28 AM, Michael Foord <fuzzy...@voidspace.org.uk> wrote: > For wrapping mutable types I'm tempted to say YAGNI. For the standard > library wrapping integers meets almost all our use-cases except for one > float. (At work we have a decimal constant as it happens.) Perhaps we could > require immutable types for groups but allow arbitrary values for individual > named values?
Whereas my opinion is that "immutable vs mutable" is such a blurry distinction that we shouldn't try to make it at the lowest level. Would it be possible to name frozenset instances? Tuples? How about objects that are conceptually immutable, but don't close all the loopholes allowing you to mutate them? (e.g. Decimal, Fraction) Better to design a named value API that doesn't care about mutability, and then leave questions of reverse mappings from values back to names to the grouping API level. At that level, it would be trivial (and natural) to limit names to referencing Hashable values so that a reverse lookup table would be easy to implement. For standard library purposes, we could even reasonably provide an int-only grouping API, since the main use case is almost certainly to be in managing translation of OS-level integer constants to named values. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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
