On Sun, Sep 29, 2019 at 5:04 AM Ricky Teachey <ri...@teachey.org> wrote:
> That's the point that I would make as well. What can you do with an
>>
> object that is only known to be Subscriptable?
>>
>> def do_subscriptable_things(obj):
>> if isinstance(obj, Subscriptable):
>> # Now what?
>
>
I'm going to echo this one -- the OP has shown that it's awkward to know
whether an arbitrary object is "subscriptable" -- but not why you'd want to
do that check at all. In fact, you do not use "EAFTP" to do a type check --
the whole point is that you use it like you expect ot use it, and if you
get an error, you know it can't be used that way:
So the OP's code:
try:
obj[0]
except TypeError:
subscriptable = False
except (IndexError, KeyError):
subscriptable = True
else:
subscriptable = True
if subscriptable:
...
Is exactly NOT EAFTP -- it's LBYL, but using exception catching to do the
type check.
And after this code is run, now what? you don't know anything about HOW you
can subscript that object -- can you use an index, can you use a key, can
you do something really wierd and arbitrary:
Maybe if you want to use/abuse it as an alternative function calling
> syntax-- square brackets rather than parentheses.
>
Like the example given a bit earlier:
class Test(object):
def __getitem__(self, idx):
return idx**2
py> squares = Test()
py> squares[5]
25
So if you think you *may* have a "callable_with_an_integer" -- the thing to
do is:
try:
result = squares[5]
except TypeError:
print("Opps, couldn't do that")
Though what you'd probably really want to do is have your oddball class
raise appropriate exceptions is the wrong kind of "index" was passed in.
If you do want to do this, maybe a "callable_with_brackets" ABC ??? (but
please don't -- there is already a way to make objects callable...)
Now that I think about it a bit more, that example *could* make sense, but
only if what you are trying to do is make an indexable lazy-evaluated
infinite sequence of all the squares -- in which case, you'd want to put a
bit more in there. And now that I think about it, there doesn't appear to
be an ABC for something that can be indexed and iterated, but does not have
a length.
However, we need to think more about what ABCs are *for* anyway -- given
Python's "magic method" system and Duck Typing, you can essentially create
types that have any arbitrary combination of functionality -- do we need an
ABC for every one? Obviously not. When I first learned about ABCs, I
thought some about what the point was -- they are NOT the same as, say,
ABCs in C++ -- Python doesn't need those. I came to the conclusion that the
point of ABCs was to allow users to write code that expects standard
built-ins that will also work with custom types that match that interface.
But it's only useful for standard Base Classes -- making a custom ABC that
matches the spec of a particular use case isn't very helpful -- unless
various third parties are going to be using that spec, there's not point in
an ABC. Modifying my point -- ABCs are useful for built ins or large
projects with a wide user base that may have third parties writing
extensions, plug ins, etc).
However, if a spec gets complicated, the ABC system breaks down anyway --
go look at what numpy is trying to do with "duck arrays" -- ABCs are not
very helpful there.
In short: in python, __getitem__ can be [ab]used for virtually ANYTHING --
so if you have an object that isn't a mapping (KeyError), or a Sequence
(IndexError), they you would need to know something more about what it is
anyway in order to use it -- I can't see how simply knowing that you can
toss some unknown type(s) of objects into the square brackets is useful.
So back to the OP:
What do you want to be able to do here? What types do you want to be able
to support, and how do you want to use them?
-CHB
--
Christopher Barker, PhD
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/TMQXH7MZBR5H2FWGZ3SQHPX4G2225YLJ/
Code of Conduct: http://python.org/psf/codeofconduct/
