python PEP suggestion

[Dan Strohl]

You mentioned that it is a bit contrary to how Python currently works, I am not sure I understand that, can you elaborate a bit?

<snip>
"Conditional execution, indexing (__index__), numeric conversions (__float__ also), and displaying are special cases related to syntax operations. <snip> You have left out the use of abstract base classes.  An iterable that can be used as a mapping can register itself as a mapping.  Json could check whether something is a sequence or mapping and iterate to get values or pairs of values."
</snip>

All of the above is true, and all of the above are various tools that can work (and I have used most of them from time to time).  However, there is a limit to how many different types of special methods that should be built in, built in, what if I want to build an object that would return a datetime or bytearray object as needed, or something more esoteric, or if I wanted to provide different types of data depending on the calling object?  

What I thinking about is something that allows the called object to return information based on the calling object, (or at least based on what the calling object wants to ask for) in a manner that makes the most sense.

This _seems_ like it fits pretty well with Python's module / library / orientation...  the library authors often do not know anything about the  ones using their objects (and should not have to).  With something like this, it allows the library author to have a "standard" way of saying, "I want data in this format".  That could be simply saying "I am json and want data that will work for me", or it could be saying "I want a datetime from you".  Then, even if the called / passed object is not mappable, or is a subclass of something totally different, the called object has the ability to respond in a way that the author of the called object chooses.

If, for example, I choose to implement an object as a mapping object (using __getitem__, subclassing userdict, using collections.abc.Mapping, or whatever), I am in general only going to be able to answer a call to object[key] one way.  I could certainly do a custom method or property but then we get back to both authors needing to coordinate more.

<snip>
Functions that unnecessarily restrict inputs to subclasses of list or dict will not be solved by this.
</snip>

Yup, it doesn't solve everything, it just provides another tool that people *could* use to write interoperable libraries and objects.

<snip>
Of course, the tranformation would be unidirectional.
</snip>

Again, yup, just like if I implemented "MyObject.__str__()", it does not guarantee that I did "MyObject('a_string')" it would work (and often doesn't).

<snip>
The excessive indents of 31 and 15 spaces make the rest of this post unnecessarily hard to read.
</snip>

Sorry about that, damn outlook tabs being expanded to stupid numbers I guess.  I will do better next time.<grin>.

Does any of that help?

Dan



-----Original Message-----
From: Python-list [mailto:python-list-bounces+d.strohl=f5.com at python.org] On Behalf Of Terry Reedy
Sent: Sunday, November 08, 2015 2:27 PM
To: python-list at python.org
Subject: Re: python PEP suggestion

On 11/6/2015 1:21 PM, 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?

At first glance, plausible, but I am not sure needed, and it seems a bit contrary to how Python currently works.



> 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)

Conditional execution, indexing (__index__), numeric conversions (__float__ also), and displaying are special cases related to syntax operations.  Functions that unnecessarily restrict inputs to subclasses of list or dict will not be solved by this.  You have left out the use of abstract base classes.  An iterable that can be used as a mapping can register itself as a mapping.  Json could check whether something is a sequence or mapping and iterate to get values or pairs of values.  Of course, the tranformation would be unidirectional.

> Proposal:
> What I am proposing is something like:
>
> object.__cast__(self, to_class):
>                                """
>                                to_class: the class type that you wish to return.
>                                """

The excessive indents of 31 and 15 spaces make the rest of this post unnecessarily hard to read.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list