[Guido]
>> Types with constructors that insist on an argument are problematic to
>> generic code that tries to instantiate a type by simply calling it.
[Greg Ewing]
> Why on earth would you be trying to instantiate something
> without having any idea what parameters are required?
For example, unpickling can need to do this when a type uses the
__getstate__ + __setstate__ pickle subsystem (it has to create an object of
the correct type before it can call that object's __setstate__ method; if
the type's constructor requires arguments, life is harder). The generic
code in copy.py faces related problems (you may well be able to mimic the
full current state of an object without having any idea how to build the
object up from scratch "correctly"; for example,
shallowcopy = obj.__class__()
shallowcopy.__dict__.update(obj.__dict__)
works fine for instances of classic classes, provided the constructor
doesn't require arguments).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4