On 05/08/2023 11.18, Chris Angelico via Python-list wrote:
On Sat, 5 Aug 2023 at 09:08, dn via Python-list <python-list@python.org> wrote:
On 03/08/2023 11.38, Jon Ribbens via Python-list wrote:
On 2023-08-02, dn <pythonl...@danceswithmice.info> wrote:
Can you please explain why a multi-part second-argument must be a tuple
and not any other form of collection-type?
The following comment may hold a clue:
if (PyTuple_Check(cls)) {
/* Not a general sequence -- that opens up the road to
recursion and stack overflow. */
https://github.com/python/cpython/blob/main/Objects/abstract.c#L2684
Plus an almost total lack of demand for change I should think.
Thanks for the reference!
Am not proposing a change (have learned 'the rule' and accepted
life-as-it-is), but was curious about the restriction: why not any
(reasonable sequence)?
There are quite a few places where the only option is a tuple.
"spam".startswith(["sp", "h"])
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: startswith first arg must be str or a tuple of str, not list
try: 1/0
... except [ValueError, IndexError]: pass
...
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
TypeError: catching classes that do not inherit from BaseException is
not allowed
It simplifies a lot of checks. Either it's a tuple or it's a single
thing. A *lot* of values are iterable, but only tuples are tuples.
As the C comment notes, this also means you don't have to worry about
recursion; otherwise, even core language features like exception
handling would have to iterate over a thing while ensuring that they
don't get stuck in self-referential objects. (Incidentally, it seems
that exception handling doesn't bother with recursion *at all*, and
won't catch "(a, (b, c))" - but even if recursion is handled, it can't
go infinite, short of some serious messing around in ctypes or the C
API.)
Yes. Thanks Chris!
The idea that such 'lists' be immutable (even, hashable), and therefore
a tuple, makes a certain amount of sense, and @Cameron mentioned
'frugality'.
My limitation is thinking only at the Python level (which as @Jon
pointed-out, is only part of the story).
Faced with a situation where an argument may be a scalar-value or an
iterable, I'll presume the latter, eg throw it straight into a for-loop.
If that fails (because the argument is a scalar), use try-except to
re-route the logic. Alternately, in an OOP situation, utilise
polymorphism so that the 'scalar' and 'iterable' instances both include
the appropriate method[name]. Accordingly, as long as the argument is an
iterable (includes an __iter__() method), the actual type/class is
more-or-less irrelevant.
However, as observed earlier - and with these additions, having learned
the 'rule', ie use a tuple; the brain is still pondering, but have
shrugged-shoulders and carried-on regardless...
--
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list
