Weak Type Ability for Python

[avi.e.gross at gmail.com]

Dennis,

Before I reply, let me reiterate I am NOT making a concrete suggestion, just having a somewhat abstract discussion.

The general topic is a sort of polymorphism I envisioned where a select group of classes/objects that can be seen as different aspects of an elephant can be handled to provide some functionality in a consistent way. We all agree much of the functionality can be done deliberately by individual programmers. The question was whether anyone had done a more general implementation or even saw any reason to do so.

Fair enough?

So let us assume I have an object, call it obj1, that encapsulates data the old fashioned way. Consider a classical case like an object holding information about a parallelopiped or something like a shoebox. How you store the info can vary, such as recording a height/width/depth, or a series of x,y,z coordinates representing some of the vertices. But no matter how you store the basic info, you can derive many things from them when asked to provide a volume or surface area or whether it will fit within another object of the same kind assuming the sides have no width. Or, you can ask it to return another instance object that has double the width or many other things.

There are several ways to provide the functionality, actually quite a few, but one is to make a method for each thing it does such as obj1.get_surface_area(), obj1.get_volume() and obj1.does_it_fit_in(cl2) and of course you can have methods that change the orientation or ask what angles it is oriented at now and whatever else you want.

Each such method will return something of a usually deterministic type. Volumes will be a double, for example. But what if you design a small language so you can type obj1.get_by_name("volume") and similar requests, or even a comma separated grouping of requests that returns a list of the answers? It now is not so deterministic-looking to a linter. But normal Python allows and often encourages such polymorphism so is this anything new?

What I envisioned is a tad closer to the latter. Not this:

a = thisType(3)
b = thisType(7)
c = 9	#plain integer
print(a + b + c)

Note the above example is standard. My thoughts are a bit more arcane and focused on convertibility of a single value into multiple forms.

Say I have a data type that stores a number representing a temperature. It may have ways to initialize (or change) the temperature so it can be input as degrees centigrade or Fahrenheit or Kelvin or Rankine or even more indirect ways such as 10 degrees Fahrenheit above the freezing point of pure water at a particular atmospheric pressure and so on.

What I want to add is a bit like this. Internally many methods may get created that may not be expected to be used except through a designated interface. Call them f1() and f2() ... fn() for now.

Also in the class initialization or perhaps in the object dunder init, you create something like a dictionary consisting of key words matched by pointers to the aforementioned functions/methods. This structure will have some name designated by the protocol such as _VIEWS and may be visible to anyone looking at the object. The details can be worked out but this is a simplistic explanation.

In this dictionary we may have words like "Celsius", "Fahrenheit" and so on, perhaps even several variants that point to the same functions. If a user wants the temperature in absolute terms, they may call a standard function like "obj1.as_type('Kelvin')" and that function will search the dictionary and get you the results using the appropriate conversion method. You may also support other accessors like 'obj1.supports_type("Fahrenheit451")' that reports as True/False whether the object can handle that output. It merely checks the internal dictionary. You may have another that returns a list of the data types as keys and whatever else is part of the design.

You can, of course, have a second set of such directives that instead of returning a temperature as a double, will return a printable text version that includes ℃ or °K or °R or °F".

A second example could be something holding a date with plenty of internal abilities to display it in a wide variety of formats or maybe just holds a day of the week that it will display as a string in any language it handles, such as Sunday being shown as:
יוֹם רִאשׁוֹן
Dimanĉo
Vasárnap
Sonntag
Dimanche
Zondag
日曜日
रविवार

And so on. Again, it need not store the text for every language but can call translation software as needed and it can be more than the name of a day of the week. It could have a dictionary containing all the languages it handles as described for another example and access methods. Of course, if called on repeatedly and often for the same languages, it could cache results.

My question, again, is not whether this can be done but whether some kind of protocol can be created that is published and suggests the names and so on to use in constructing your own implementation. And, it may be helpful if a module is made available that makes it even simpler to use.

I think it is time for me to drop out of this discussion unless I hear something of interest. It is just an idea I have been pondering. 

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com at python.org> On Behalf Of Dennis Lee Bieber
Sent: Friday, April 14, 2023 12:23 AM
To: python-list at python.org
Subject: Re: Weak Type Ability for Python

On Thu, 13 Apr 2023 20:53:21 -0400, Richard Damon
<Richard at Damon-Family.org> declaimed the following:

>On 4/13/23 7:25 PM, avi.e.gross at gmail.com wrote:
>> s there any concept in Python of storing information in some way, such as
>> text, and implementing various ideas or interfaces so that you can query if
>> the contents are willing and able to be viewed in one of many other ways?
>
>There is nothing that I know of built into Python that does this.
>
>There is no reason you can't write your own class to implement this. 
>Something that by "default" looks like a string, but in some contexts 
>(operated on by certain types) sees if its string could be treated as a 
>value of some other type, and if so, converts its value to that type and 
>does the operation.

	I sure don't want to see the documentation for that...

a = thisType(3)
b = thisType(7)
c = 9	#plain integer

print(a + b + c)

(Since I presume left to right evaluation of equal level operations) Does
this result in

			46 ("3" + "7" => "37", int("37") + 9 => 46)

or

			19 (as int("3") + int("7") => 10, + 9 => 19)

	Worse... changing order of a/b/c would make completely different
results...

			82 (b + a + c)
			127 (int(a) + c returning thisType(12) + b as strings)

and does (c + a) result in returning an integer (a conforming to c); or a
string (a coercing c to thisType).
			
-- 
https://mail.python.org/mailman/listinfo/python-list