Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Piergiorgio Sartor
 <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de>
Newsgroups: comp.lang.python
Subject: Re: Two python issues
Date: Tue, 5 Nov 2024 22:27:53 +0100
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <p7fqvk-jt4.ln1@lazy.lzy>
References: <700403c2-e052-4670-b2ec-eaf9b4babada@pandora.be>
 <mailman.80.1730839406.4695.python-list@python.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 05 Nov 2024 22:28:42 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2a0534154ec88a34d27315aba77c9ccb";
	logging-data="1812733"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/0QlSuaTuOtofzX8yKA580"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:0LVOYi4X9FqckxeyNHL/h61+rLU=
Content-Language: it, en-GB
In-Reply-To: <mailman.80.1730839406.4695.python-list@python.org>
Bytes: 2993

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