To me, it looks like, to the contrary, that Python is so full of counter-intuitive bits... like doing a［begin:end+1］ to take a slice.
A few years ago, I worked in a neuroimaging research lab and taught some basic Python programming to quite a few research assistants with psych degrees. At the time, a scientific computing or intro to programming course wasn't part of the psych curriculum at the university that the lab was. 0-indexed arrays were often a big sticking point. It just didn't mesh with their intuition.
For example, if `len(some_list)` returned 2, they would try to get the last value with `some_list[2]` and then get confused. Or for another example, if they used `for i in range(n)`, they'd be confused when `i` didn't start at 1 and end at n. They eventually caught on and learned further syntax such as `some_list[-1]` for getting the last value in a list. But, it was a bit of a frustrating experience for both them and myself because I only had time to teach them the basics and some google-fu as well as give them some example code. While 0-indexing was a source of a lot of their bugs in the beginning, I learned that the best method for them to get the hang of it was to encourage them to do a lot of print debugging, which was more than adequate for any scripts they'd be writing. They just really needed more feedback from what they wrote and what it actually did to get a better grasp of the idiosyncrasies of programming vs. their intuition.
Side note: The frustration of teaching non-techies Python was nothing compared to teaching them LaTeX. I was luckily able to eventually convince the PI to adopt Overleaf and organizing the text into separate files and using `\include` or `\input` to reduce the headache of collaborative writing as well as move all the internal docs to markdown. The latter became a huge help when we eventually moved to Jupyter notebooks for a lot of our python-related scripts as the team members already became adept enough with markdown. It was also easier to teach everyone how to use pandoc for making pretty PDFs of the internal docs or converting their markdown drafts into LaTeX.
It is all a matter of what one is used to. Quoting myself:
> I guess counter-intuitiveness is in the eye of the beholder.
1-indexed arrays are not common in programming languages. There is nothing wrong with them, but most languages are 0-indexed, so for most programmers a 1-indexed language is something slightly unexpected.
For non-programmers it might be different.
> Given the premices on which the Python language was designed (giving access to programming to non-programmers)
I had college lectures using 0 as start index, others using 1, both were fine, no problem.
However taking a slice with ［start:end+1］ is unequivocally counterintuitive.
I see your point, but personally find it a matter of preference, not of objective truth.
`range(end+1)` is consistent with that slice notation that you disapprove of.
At the same time, on 0-indexed vs 1-indexed you seem to have no preference (I prefer 0 for historical reasons).
How about `len(items)` vs `items.length`? I have my own preferences there, but I would not say any or the other is intrinsically better.
Anyway, I already wrote way too much about such a small syntax thing :)
They could have added, in parallel to range(start,end+1), some interval() function that would adopt the more sensible syntax interval(start,end), and then design the slice syntax on this new interval() one.
And to begin with, why on Earth is range() using the syntax range(start,end+1)? I honestly can't understand why it was so important for the language designers to calque it on the (barely) most common idiom in C "for (int i=begin; i<end+1; ++i)" which can by the way very well be replaced by "for (int i=begin; i<=end; ++i)".
While they were at designing a sugar syntax for slicing (and the same applies for range), why didn't they internalize the "i<end+1" quirk by doing the conversion in the implementation code???
> How about `len(items)` vs `items.length`?
This, poses no problem to me. Just a different language, nothing hurting my sense of logic like [start:end+1] does. Same for 0 vs 1, just convention, fine by me.
> measure theory
First of all, even for a specialist, that extremely hard to be delusioned into thinking we're doing measure theory, when we're manipulating indices of arrays/matrices/tensors.
But anyways, assuming you think it's measure theory. I'm trained in the field and that's impossible to expect half-open intervals in this particular place!
To the contrary: the support of base elements of major functional spaces used in measure theory textbooks are always compacts.
I didn't mean to advocate at all... Just explained that I never peronally felt the weirdness of it.
The point about integers is taken but Python style also gives you len(range(n, n+k)) == k and len(range(n, k)) == n - k which is very convenient at times.
> To the contrary: the support of base elements of major functional spaces used in measure theory textbooks are always compact.
You can take either type of intervals to define Borel sigma algebras.
Half-open intervals, however, additionaly form a semiring while finite unions of half-open intervals additionaly form a ring - the starting point of Caratheodory's extension theorem [1] which is kind of essential at least in some expositions.
[1]: https://en.m.wikipedia.org/wiki/Carath%C3%A9odory%27s_extens...