All,
I wanted to run the following thought past the list as a possible PEP
enhancement suggestion to see if it feels like something that is worth
proposing. I know it is not in the PEP format at this point, I can, and will,
clean it up if needed, I am just trying to throw it against the wall at this
point to see if it resonates... (or if it falls flat and goes "splat" <grin>).
Thoughts?
Dan Strohl
New special method name to allow for more flexible object type casting/access,
and extend type() to cast objects using this special method name.
Overview:
Have a new special method name that would allow a given objects to request
information from another object in a given type, or to cast an object into a
different type, and extend the built in type() function to use this.
Rationale:
There is currently __str__, __int__, and __bool__ that allow me to tell an
object how it should reply to a request for these types of basic data types.
However if I want to access a copy of the objet in dict form, or as a list, or
if I am trying to convert something using json, there is no standard way of
doing that for a custom object (I know I can do __getitem__ and/or __iter__,
but I many processes don't try these if the object is not a subclass of dict or
list/tuple)
Proposal:
What I am proposing is something like:
object.__cast__(self, to_class):
"""
to_class: the class type that you wish to return.
"""
-and-
Class type(object, to_class):
"""
With two arguments, will attempt to cast "object"
into "to_class" if possible. This would be done by something like the
following:
(with 1 and 3 arguments, will work as currently
designed)
"""
Type(object, to_class):
If isinstance(to_class, (int, str,
bool)):
Return
to_class(object)
Else:
Try:
Return object.__cast__(to_class):
Except
AttributeError:
#
yes, I know this should be more readable!
Raise TypeError('object x could not be converted to type y")
This allows for more customization on how a developer would want to return this
object in various forms, and if, for example, the custom object was passed to
something like json.dumps, it could try converting the object to something it
recognizes first, or even try doing something like type(custom_object, json)
and see what returned.
So, in implementation I might do something like:
def __conv__(self, to_class):
if isinstance(to_class, (json, dict)):
return self._data_dict
elif isinstance(to_class, ElementTree):
return self._get_xml_dict()
else:
raise TypeError('could not convert
object to class')
This allows for developers of classes that operate on data passed to be able to
define a process that they would use to accept unknown objects, without having
to worry about handling all of the different potential object types, and pass
the responsibility for how to structure the information to the developer of the
custom object.
--
https://mail.python.org/mailman/listinfo/python-list
