On Fri, Jul 21, 2017 at 8:49 AM, Serhiy Storchaka <storchaka@gmail.com> wrote:
20.07.17 04:35, Alexander Belopolsky пише:
On Wed, Jul 19, 2017 at 9:08 PM, Guido van Rossum <guido@python.org> wrote:
The proposal in your email seems incomplete
The proposal does not say anything about type((x=1, y=2)). I assume it will be the same as the type currently returned by namedtuple(?, 'x y'), but will these types be cached? Will type((x=1, y=2)) is type((x=3, y=4)) be True?.
Yes, this is the key problem with this idea.
If the type of every namedtuple literal is unique, this is a waste of memory and CPU time. Creating a new type is much more slower than instantiating it, even without compiling. If support the global cache of types, we have problems with mutability and life time. If types are mutable (namedtuple classes are), setting the __doc__ or __name__ attributes of type((x=1, y=2)) will affect type((x=3, y=4)). How to create two different named tuple types with different names and docstrings?
How about just making a named namedtuple if you want to mutate the type? Or perhaps make help() work better for __doc__ attributes on instances. Currently,
class Foo: pass ... f = Foo() f.__doc__ = "Hello" help(f)
does not show "Hello" at all. In Python 2 all types are immortal, in python 3 they can be collected as
ordinary objects, and you can create types dynamically without a fear of spent too much memory. If types are cached, we should take care about collecting unused types, this will significantly complicate the implementation.
Hmm. Good point. Even if making large amounts of arbitrary disposable anonymous namedtuples is probably not a great idea, someone might do it. Maybe having a separate type for each anonymous named tuple is not worth it. After all, keeping references to the attribute names in the object shouldn't take up that much memory. And the tuples are probably often short-lived. Given all this, the syntax for creating anonymous namedtuples efficiently probably does not really need to be super convenient on the Python side, but having it available and unified with that structseq thing would seem useful. -- Koos -- + Koos Zevenhoven + http://twitter.com/k7hoven +