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 <[email protected]> On
Behalf Of Dennis Lee Bieber
Sent: Friday, April 14, 2023 12:23 AM
To: [email protected]
Subject: Re: Weak Type Ability for Python
On Thu, 13 Apr 2023 20:53:21 -0400, Richard Damon
<[email protected]> declaimed the following:
>On 4/13/23 7:25 PM, [email protected] 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
--
https://mail.python.org/mailman/listinfo/python-list
