Leo added the comment: 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 <rep...@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 <rep...@bugs.python.org> > <http://bugs.python.org/issue22562> > _______________________________________ > ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue22562> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
