Hi Mathew, welcome!
My responses interleaved with your comments.
On Wed, Nov 25, 2020 at 04:29:17AM +0000, Mathew M. Noel via Python-ideas wrote:
> As discussed earlier on the post on 'Circular Indexing', considering
> interpreting indices that lie outside the range 0 to n-1 modulo n for
> list indexing. Thus element n corresponds to element 0, n+1 to element
> 1 and so on. This has two consequences:
>
>
> 1.) Makes the Python convention of interpreting index -1 as the last
> element more logical since -1 is the same as n-1 when taken modulo n.
The convention is logical enough as it is. If doesn't need justification
based on modular arithmetic.
> If -1 is the first element then to be logically consistent we have to
> interpret index n as the element 0 as well!
No we don't. There is no logical consistency in arguing that index n
**must** be interpreted as element 0. Don't mistake your *preference*
for circular/modular indexing for *logical necessity*.
It is totally logically consistent to treat indexes as *linear* not
circular, with zero-based indexing starting from the front of the
sequence and negative indexes starting from the end.
> Obviously this does allow certain errors to slip
Indeed. That's a much stronger argument against your proposal than
the weak argument from "logical consistency" for your proposal.
> but if you are going
> to allow an index of -1 (indices that occur before 0) then you might
> just as well allow indices above n-1 to be logically consistent.
That doesn't follow even a little bit. We're under no obligation to
totally break a perfectly good, useful and logical model for indexing,
changing it to a *worse* model, under a dubious and unjustified claim
that we "might as well" change the model to be "logically consistent".
We don't add language features because we "might as well", we add them
because they will improve the language.
The current model is already logically consistent. Moving to a circular
model might be useful in a tiny fraction of cases, but will be worse for
most cases.
But the fatal objection is that it will *break backwards compatibility*
and therefore change the meaning of existing code. That rules out this
change without a long period of deprecating the existing behaviour,
followed by adding the new behaviour. And we don't do that just for a
small benefit.
Two examples of how a circular model will break existing code (there
may be more):
1. The "sequence protocol" for iteration.
The sequence protocol relies on calling `sequence[0]`, `sequence[1]`,
and so forth, for increasing indices 0, 1, 2, 3, 4, ... until IndexError
is raised. If we shift to a circular model, IndexError will not be
raised, and sequences which are iterable today will turn into infinite
loops under your proposal.
2. Slicing past the end index. Under the current design:
>>> a = "abcdefgh"
>>> a[3:10]
'defgh'
Under your proposal:
>>> a[3:10] # proposed behaviour
'defghab'
Both of these are changes in behaviour, so would need to have a
significant benefit over the status quo to justify breaking people's
code.
> 2.) If circular indexing is used then instead of using a double FOR
> loop to go through a loop twice we can iterate from 0 to 2n !
Do you often need to go through a loop twice? Can you give an example?
> Although trivial for the case of one dimensional lists/arrays,
> cylindrical indexing (for 2D arrays) and toroidal indexing (2D, 3D and
> nD arrays) schemes might be worth exploring for n-dimensional NumPy
> arrays.
I think you have the process backwards. We don't change the language
because the proposal "might be worth exploring". Do your exploring
first, and only if you find some really useful benefits of the proposal
will we consider changing the language.
Python is not an experimental toy language with ten users. It is one of
the most popular languages in the world, relied upon by tens or hundreds
of thousands of people. We don't change existing behaviour and break
people's code because it "might be useful".
> Circular and in general cylindrical or toroidal indexing schemes might
> simplify coding by reducing the number of FOR loops when iterating
> over nD arrays in NumPy.
Same again. *First* prove that it will do these things, then we consider
whether the benefit is worth the disruption.
If you are claiming a benefit for numpy, have you asked numpy developers
what they think of your proposal?
--
Steve
_______________________________________________
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/KZ7LZZHXDG57ZFYU7XRPB7O5VQ6LQCTG/
Code of Conduct: http://python.org/psf/codeofconduct/
