[Python-Dev] Method __func__ objects are unpicklable
During some sophisticated pickling I noticed that method `__func__` objects are unpicklable, because they share the name with the bound method object itself. ``` from pickle import dumps class A: @classmethod def b(cls): pass print(A.b) # > print(A.b.__func__) # dumps(A.b) # works dumps(A.b.__func__) # breaks # >Traceback (most recent call last): # > File "", line 1, in # >_pickle.PicklingError: Can't pickle : # >it's not the same object as __main__.A.b ``` The last call compains that global symbol "A.b" is not the same object as `A.b.__func__`. Everything would work if the `__func__` objects had the suffix ".__func__" in their qualname. Actually setting the qualname of the `__func__` object makes it picklable, but then the bound method object is unpicklable, as it inherits the name from the `__func__`. It would be good if they were separate. This is an attempt at emulating the desired behavior: ``` from pickle import dumps class A: pass def c(cls): pass A.c = lambda: c(A) A.c.__qualname__ = "A.c" A.c.__name__ = "c" A.c.__self__ = A A.c.__func__ = c A.c.__func__.__qualname__ = "A.c.__func__" print(A.c) # print(A.c.__func__) # dumps(A.c) # works dumps(A.c.__func__) # works ``` Can we make the `__func__` objects picklable this way? haael ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/N2J6MVLURTBAB5PJLJG3LO6U4PTPJMU2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
Sorry if I am asking the obvious, but why are the aliases of set types not included in the 'types' module? I thought for a moment that they are just classes, but no, they introduce themselves as built-in types, just like any other standard Python type. > print type(set([1, 2, 4])) > print type(frozenset([3, 5])) Is it intentional, or is there some meaning behind this? If not, shouldn't they be added to the module? Regards, Bartosz Tarnowski --- Darmowy program do wypełniania PIT: http://linkint.pl/f2931 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
Because there's no reason to include them, since they are already in the root (builtins) namespace. You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means: OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least. Regards, Bartosz Tarnowski - Ksiegowa radzi: Jak zaÅozyc firme w 15 minut? http://linkint.pl/f2968 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?
Because there's no reason to include them, since they are already in the root (builtins) namespace. You'll notice that in Python 3, the "types" module only contains types which are not obviously accessed through easier means: OK, makes sense, but in this case it would be handy to have some list of all possible built-in types. I was just creating one and I nearly missed sets. If an entry in 'types' module is too much, there should be some comprehensive list in the documentation at least. Maybe this is what you're after? pprint([t for t in object.__subclasses__() if t.__module__ == '__builtin__']) [, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ] Jean-Paul Yes, something like that, but without abstract types like 'basestring'. If abstract types were OK, it would suffice to use 'object'. The use case is designing protocols that export Python objects to outer world, 'pickle' is an example. One needs to typecase through all built-in Python types and handle them in some way. Nevertheless, my problem is solved. Thank you. Regards, Bartosz Tarnowski --- Darmowy program do wypeÅniania PIT: http://linkint.pl/f2931 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
