L.S.,

Python seem to suffer from a few poor design decisions regarding strings
and lists that affect the elegance of the language.

(a) An error-prone "feature" is returning -1 if a substring is not found
by "find", since -1 currently refers to the last item. An example:

>>> s = 'qwertyuiop'
>>> s[s.find('r')]
'r'
>>> s[s.find('p')]
'p'
>>> s[s.find('a')]
'p'
>>>

If "find" is unsuccessful, an error message is the only clean option.
Moreover, using index -1 for the last item is a bad choice: it should be
len(s) - 1 (no laziness!).
Negative indices should be reserved for elements preceding the element
with index 0 (currently not implemented, but a must for orthogonal
design supporting general sequences).

(b) When using assignment for slices, only lists with the same length as
the slice should be acceptable, otherwise an error should be given. 
Anything that re-indexes items not covered by the slice is against the
essential idea of assignment. For changes that imply re-indexing (e.g.,
inserting a list longer than the slice), Python offers cleaner solutions.

Comments are welcome.

With best regards,

Raymond

On 05/11/2024 15.48, Raymond Boute wrote:
> L.S.,
>
> Python seem to suffer from a few poor design decisions regarding strings
> and lists that affect the elegance of the language.
>
> (a) An error-prone "feature" is returning -1 if a substring is not found
> by "find", since -1 currently refers to the last item. An example:
>
> >>> s = 'qwertyuiop'
> >>> s[s.find('r')]
> 'r'
> >>> s[s.find('p')]
> 'p'
> >>> s[s.find('a')]
> 'p'
> >>>
>
> If "find" is unsuccessful, an error message is the only clean option.
> Moreover, using index -1 for the last item is a bad choice: it should be
> len(s) - 1 (no laziness!).
> Negative indices should be reserved for elements preceding the element
> with index 0 (currently not implemented, but a must for orthogonal
> design supporting general sequences).
>
> (b) When using assignment for slices, only lists with the same length as
> the slice should be acceptable, otherwise an error should be given.
> Anything that re-indexes items not covered by the slice is against the
> essential idea of assignment. For changes that imply re-indexing (e.g.,
> inserting a list longer than the slice), Python offers cleaner solutions.
>
> Comments are welcome.

To write the nested expression, s[s.find(...)] it
means you're 200% sure of what happens in case of
not found.
It could be -1 or None or [] or anything.

So, the really correct thing to do, since you know
what will happen in case of not found, is *not* to
write the nested form, but explicitly state what it
will happen.

r = s.find(...)
if r is good:
s[r]
else:
print('not found')

Which is much easier to read, to debug, etc.

To paraphrase someone: "If the length of a
program would be measured by the time needed
to understand it, some programs are too short
to be short."

bye,

--

piergiorgio

On Tue, 5 Nov 2024 22:27:53 +0100, Piergiorgio Sartor wrote:

> To write the nested expression, s[s.find(...)] it means you're 200% sure
> of what happens in case of not found.

Or use s.index(...) instead of s.find(...). Then you get an exception if
the substring is not found, instead of having your program produce some
mysteriously-incorrect result.

Raymond Boute <raymond.boute@pandora.be> wrote or quoted:
> >>> s[s.find('a')]
>'p'

If you want exceptions, index() is your jam.

>Moreover, using index -1 for the last item is a bad choice: it should be
>len(s) - 1 (no laziness!).

This feature is the bee's knees, man.

last_item = my_list[ -1 ]
second_to_last = my_list[ -2 ]

Way cleaner than my_list[ len( my_list )- 1 ], don't you think?

>(b) When using assignment for slices, only lists with the same length as
>the slice should be acceptable, otherwise an error should be given. 

The current setup lets you pull off some seriously gnarly code
maneuvers:

python
# Insert elements
my_list[ 2: 2 ]=[ 4, 5, 6 ]

# Replace a section
my_list[ 1: 4 ]=[ 10, 11 ]

# Delete elements
my_list[ 2: 5 ]= []

These moves are slick and expressive. Forcing exact length
matching would only cramp our style.

Look, I get it. You're probably fresh out of coding bootcamp,
thinking you can reinvent the wheel. But trust me, these features
are solid gold. They're not perfect, sure, but they're about
as good as finding a parking spot in San Francisco on a Saturday
night. So before you go throwing shade at Python, maybe spend
some more time with it. You might just find it grows on you like
a NorCal redwood. Keep coding, and don't let the fog get you down!