Re: Two python issues

2024-11-06 Thread Roel Schroeven via Python-list

Op 5/11/2024 om 15:48 schreef Raymond Boute via Python-list:

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:
This is IMO indeed not the best design decision. Fortunately there's an 
alternative: the "index" method on strings, which raises exception 
ValueError when the substring is not found, instead of returning -1. An 
example:


>>> s = 'qwertyuiop'
>>> s[s.index('p')]
'p'
>>> s[s.index('a')]
Traceback (most recent call last):
  File "", line 1, in 
    s[s.index('a')]
ValueError: substring not found

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).
I don't agree, I think this is a case of "practicality beats purity". 
Being able to use negative indices to index from the end is often very 
useful in my experience, and leads to code that is much easier to grok. 
General sequences on the other hand is a concept that I don't see ever 
implemented in Python (or most other programming languages AFAIK). I 
think it would be wrong to avoid implementing a feature that's very 
useful in practice in order to keep the door open for a theoretical 
feature that's probably not even wanted in the language.
(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.
Again I don't agree. I don't see anything wrong with replacing a part of 
a list with something that's longer, or shorter, or even empty. It's 
very practical, and I don't see how it's against the essential idea of 
assignment (or actually I'm not even sure what you mean by that).


Two closing remarks:

(1) I think that Python indeed has some warts, inconsistencies, gotchas. 
I think this is unavoidable in any complex system. Python got rid of a 
number of those in the transition from Python 2 to Python 3; others 
might remain forever. Overall though I feel Python is more consistent 
than most other programming languages I come in contact with.


(2) Design decisions are not necessarily wrong when they don't match 
your mental model, or don't match what you know from other languages. 
Often there are different valid options, each with their own tradeoffs.


--
"Programming today is a race between software engineers striving to build bigger
and better idiot-proof programs, and the Universe trying to produce bigger and
better idiots. So far, the Universe is winning."
-- Douglas Adams

--
https://mail.python.org/mailman/listinfo/python-list


Re: Two python issues

2024-11-06 Thread Piergiorgio Sartor via Python-list

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
--
https://mail.python.org/mailman/listinfo/python-list


Re: Specifying local dependency with Poetry

2024-11-06 Thread Loris Bennett via Python-list
Greg Ewing  writes:

> On 6/11/24 4:13 am, Loris Bennett wrote:
>> [tool.poetry.dependencies]
>> python = "^3.6"
>> first-package = "^1.6.0"
>>Could not find a version that satisfies the requirement
>> first-package<2.0.0,>=1.6.0 (from second-package==0.5.0) (from
>> versions: )
>> No matching distribution found for first-package<2.0.0,>=1.6.0 (from 
>> second-package==0.5.0)
>
> What version number does first-package have?
>
> The caret in the specification "^1.6.0" restricts it to 1.x.x versions.
>
> If you don't want that restriction, use ">=" instead.

The first package has the version number 1.6.0.

-- 
This signature is currently under constuction.
-- 
https://mail.python.org/mailman/listinfo/python-list