[issue22562] Singleton pattern for namedtuple

Eric V. Smith added the comment: You might want to check out https://bitbucket.org/ctismer/namelesstuple, which uses a similar approach. -- nosy: +eric.smith ___ Python tracker

[issue22562] Singleton pattern for namedtuple

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 generall

[issue22562] Singleton pattern for namedtuple

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 i

[issue22562] Singleton pattern for namedtuple

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

[issue22562] Singleton pattern for namedtuple

Mark Dickinson added the comment: I don't think this is a good idea. Remember that Python classes are themselves mutable objects, so if a library that you happen to import creates a "Point" namedtuple with fields "x" and "y" and class-level modifications (extra attributes, patched-in methods)

[issue22562] Singleton pattern for namedtuple

Changes by Mark Dickinson : -- versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22562] Singleton pattern for namedtuple

New submission from Leo: Each call of namedtuple will create a new class object even if an equal class, i.e. for the same fields has been created before. Applying the singleton pattern would be more efficient at least in two respects: * it would reduce the number of class objects. * checking f