Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #196959 > unrolled thread

Two python issues

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Two python issues Raymond Boute <raymond.boute@pandora.be> - 2024-11-05 15:48 +0100
    Re: Two python issues Piergiorgio Sartor <piergiorgio.sartor.this.should.not.be.used@nexgo.REMOVETHIS.de> - 2024-11-05 22:27 +0100
      Re: Two python issues (Posting On Python-List Prohibited) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-11-05 21:56 +0000

#196959 — Two python issues

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

[toc] | [next] | [standalone]

#196964

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

[toc] | [prev] | [next] | [standalone]

#196966 — Re: Two python issues (Posting On Python-List Prohibited)

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web