A use case for the singleton pattern arises when
- field names are known only at runtime, and
- you have a large number of instances with the same field names.

An example is the storage of metadata for datasets when a hashable
type is needed.

I agree that it will generally be possible to implement the singleton
pattern by wrapping collections.namedtuple. And I recognise that the
singleton pattern would make both old and new code vulnerable to side
effects caused by "mutated" classes. These side effects may well
outweigh any efficiency gains to be reaped.
I therefore withdraw the idea.

Leo

On 06/10/2014, R. David Murray <report@bugs.python.org> wrote:
>
> R. David Murray added the comment:
>
> Agreed.  If you want it to be a singleton in your code, use the singleton
> pattern in your code...but it is hard for me to see why that would be a good
> idea :) (ie: DRY).  Globally, it does not seem to me that there are likely
> to be any significant number of identical definitions in non-related
> codebases, even absent the mutable-class issue.
>
> ----------
> nosy: +r.david.murray
> resolution:  -> rejected
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue22562>
> _______________________________________
>