Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #98455 > unrolled thread

python PEP suggestion

Back to article view | Back to comp.lang.python

Contents

  python PEP suggestion Dan Strohl <D.Strohl@F5.com> - 2015-11-06 18:21 +0000
    Re: python PEP suggestion André Roberge <andre.roberge@gmail.com> - 2015-11-08 14:02 -0800

#98455 — python PEP suggestion

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.

[toc] | [next] | [standalone]

#98479

On Sunday, 8 November 2015 11:35:32 UTC-4, Dan Strohl  wrote:
> 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
>
Snip

You might want to post this to the python-ideas list.

André

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web