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....@python.org] On
Behalf Of Terry Reedy
Sent: Sunday, November 08, 2015 2:27 PM
To: python-list@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
--
https://mail.python.org/mailman/listinfo/python-list
