Type hints - am I doing it right?
Hi all I am adding type hints to my code base. I support three databases - sqlite3, Sql Server, PostgreSQL. The db parameters are kept in an ini file, under the section name 'DbParams'. This is read on program start, using configparser, and passed to a function config_database() in another module with the argument cfg['DbParams']. In the other module I have this - def config_database(db_params): To add a type hint, I now have this - def config_database(db_params: configparser.SectionProxy): To get this to work, I have to add 'import configparser' at the top of the module. I have three separate modules, one for each database, with a subclass containing the methods and attributes specific to that database. Each one has a connect() method which receives db_params as a parameter. Now I have to add 'import configparser' at the top of each of these modules in order to type hint the method. This seems verbose. If it is the correct way of doing it I can live with it, but I wondered if there was an easier way. BTW I have realised that I can bypass the problem by converting db_params to a dict, using dict(cfg['DbParams']). But I would still like an answer to the original question, as I am sure similar situations will occur without such a simple solution. Thanks Frank Millman -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE editor suggestion.
On 2023-12-13 01:28, Steve GS via Python-list wrote: Does anything from the Visual Studio family of software have a pull down menu that lists previous searches so that I don’t have to enter them every time? SGA Visual Studio search box has a dropdown list that's shown when you press the down arrow key. -Original Message- From: Friedrich Romstedt Sent: Tuesday, December 12, 2023 12:52 PM To: Steve GS Cc: python-list@python.org Subject: Re: IDLE editor suggestion. Hi! Am Di., 12. Dez. 2023 um 09:28 Uhr schrieb Steve GS via Python-list : Maybe this already exists but I have never seen it in any editor that I have used. You might want to choose Microsoft Code from its Visual Studio family of software, or, if you're ready for a deep dive, you might try using vim. Personally I am using both. HTH, Friedrich -- https://mail.python.org/mailman/listinfo/python-list
RE: IDLE editor suggestion.
Does anything from the Visual Studio family of software have a pull down menu that lists previous searches so that I don’t have to enter them every time? SGA -Original Message- From: Friedrich Romstedt Sent: Tuesday, December 12, 2023 12:52 PM To: Steve GS Cc: python-list@python.org Subject: Re: IDLE editor suggestion. Hi! Am Di., 12. Dez. 2023 um 09:28 Uhr schrieb Steve GS via Python-list : > > Maybe this already exists but > I have never seen it in any > editor that I have used. You might want to choose Microsoft Code from its Visual Studio family of software, or, if you're ready for a deep dive, you might try using vim. Personally I am using both. HTH, Friedrich -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE editor suggestion.
On 12/12/23 13:50, Thomas Passin via Python-list wrote: On 2023-12-12 08:22, Steve GS via Python-list wrote: > Maybe this already exists but > I have never seen it in any > editor that I have used. > > It would be nice to have a > pull-down text box that lists > all of the searches I have > used during this session. It > would make editing a lot > easier if I could select the > previous searches rather than > having to enter it every time. > > If this is inappropriate to > post this here, please tell me > where to go. > Life should be so > complicated. > EditPad has this. So do Notepad++, EditPlus (not free but low cost, Windows only, and very good), and I'm sure many others that are much simpler than Visual Studio Code, for example. Every now and then I pop up and suggest people look at Eric. Odd name for an editor? Well, it continues the long pun history in the Python world (Eric Idle... get it?). It has search history, among many other things, I think once it was considered to be sort of IDLE++, but it's grown to a lot more than that. Not saying Eric is better-than-XYZ-IDE, but it is a cool project... -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE editor suggestion.
On 2023-12-12 08:22, Steve GS via Python-list wrote: > Maybe this already exists but > I have never seen it in any > editor that I have used. > > It would be nice to have a > pull-down text box that lists > all of the searches I have > used during this session. It > would make editing a lot > easier if I could select the > previous searches rather than > having to enter it every time. > > If this is inappropriate to > post this here, please tell me > where to go. > Life should be so > complicated. > EditPad has this. So do Notepad++, EditPlus (not free but low cost, Windows only, and very good), and I'm sure many others that are much simpler than Visual Studio Code, for example. -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE editor suggestion.
Hi! Am Di., 12. Dez. 2023 um 09:28 Uhr schrieb Steve GS via Python-list : > > Maybe this already exists but > I have never seen it in any > editor that I have used. You might want to choose Microsoft Code from its Visual Studio family of software, or, if you're ready for a deep dive, you might try using vim. Personally I am using both. HTH, Friedrich -- https://mail.python.org/mailman/listinfo/python-list
Re: IDLE editor suggestion.
On 2023-12-12 08:22, Steve GS via Python-list wrote: Maybe this already exists but I have never seen it in any editor that I have used. It would be nice to have a pull-down text box that lists all of the searches I have used during this session. It would make editing a lot easier if I could select the previous searches rather than having to enter it every time. If this is inappropriate to post this here, please tell me where to go. Life should be so complicated. EditPad has this. -- https://mail.python.org/mailman/listinfo/python-list
RE: A problem with str VS int.
Roel, I sent a similar reply in private to someone who may not be listening as their mind is made up. This points to a serious problem with people not testing hypotheses adequately. Perhaps for homework, we can assign a request for a Python program that creates a random sample of quite a few digit strings of lengths from say 1 to 5 and compares then to each other as strings and then as integer representations and prints out whether the two methods match or not. Perhaps that might get them to discard the hypothesis and be a bity more open. I still have had to deal with people who want to know why "two" is more than "three" and truly do not understand that just because a human sees "two" as a number, that does not mean anything about another human in whose language it may be "zwei" let alone a computer program not expecting character strings to mean anything unless programmed to examine them a certain way. And often, the same people cannot sole a simple puzzle like "SEND" + "MORE" == "MONEY" -Original Message- From: Python-list On Behalf Of Roel Schroeven via Python-list Sent: Tuesday, December 12, 2023 3:58 AM To: python-list@python.org Subject: Re: A problem with str VS int. Op 12/12/2023 om 9:22 schreef Steve GS via Python-list: > With all these suggestions on > how to fix it, no one seems to > answer why it fails only when > entering a two-digit number. > One and three work fine when > comparing with str values. It > is interesting that the > leading 0 on a two digit > worked. Still, one digit and > three digit work but not two. Three-digit numbers work because you're comparing to another three-digit numbers. When two integer numbers have the same number of digits, their lexicographical ordering matches their numeric ordering. One-digit numbers don't work fine: >>> "5" < "400" False even though we can construct cases where it seems as if they do: >>> "1" < "400" True Two-digit numbers sometimes seem to work: >>> "30" < "400" True But other times clearly don't work: >>> "50" < "400" False String comparison first looks at the first characters of both operands. If they are different (as in the examples above), their ordering is used regardless of all the other characters that come after, and regardless of the length of the string. Try working through some examples (make sure to pick examples with a wide variety of first digits) and you'll see why it sometimes seems to work, but very unreliably. -- "In the old days, writers used to sit in front of a typewriter and stare out of the window. Nowadays, because of the marvels of convergent technology, the thing you type on and the window you stare out of are now the same thing.” -- Douglas Adams -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: A problem with str VS int.
On 12/12/23 21:22, Steve GS wrote: With all these suggestions on how to fix it, no one seems to answer why it fails only when entering a two-digit number. One and three work fine when comparing with str values. It is interesting that the leading 0 on a two digit worked. Still, one digit and three digit work but not two. This is now more of a curiosity as I did use the integer comparisons. Emphasis on the word "seems"! Did you try running the code provided earlier? Did you notice that such illustrated what happens when using strings which appear as numbers, and showed how a three digit number (expressed as a string) may well precede a two- (or even a one-) digit number in the same form - and that the end-result of the sequence of integers is quite-different to the sequence of integer-values expressed as strings! Why does this happen? Because of the way data is encoded. It is language independent. The definition of order or sequence is called "collation". "Comparisons" establish relative-sequence. You will find some handy explanations of how comparisons work (eg equals or less-than) in the Python manual. After working through those three steps, if there's something that's still mystifying, please refine the question... Web.Refs: https://en.wikipedia.org/wiki/Collation https://docs.python.org/3/reference/expressions.html?highlight=comparison#value-comparisons https://docs.python.org/3/howto/sorting.html?highlight=sort -- Regards, =dn -- https://mail.python.org/mailman/listinfo/python-list
Re: A problem with str VS int.
Op 12/12/2023 om 9:22 schreef Steve GS via Python-list: With all these suggestions on how to fix it, no one seems to answer why it fails only when entering a two-digit number. One and three work fine when comparing with str values. It is interesting that the leading 0 on a two digit worked. Still, one digit and three digit work but not two. Three-digit numbers work because you're comparing to another three-digit numbers. When two integer numbers have the same number of digits, their lexicographical ordering matches their numeric ordering. One-digit numbers don't work fine: >>> "5" < "400" False even though we can construct cases where it seems as if they do: >>> "1" < "400" True Two-digit numbers sometimes seem to work: >>> "30" < "400" True But other times clearly don't work: >>> "50" < "400" False String comparison first looks at the first characters of both operands. If they are different (as in the examples above), their ordering is used regardless of all the other characters that come after, and regardless of the length of the string. Try working through some examples (make sure to pick examples with a wide variety of first digits) and you'll see why it sometimes seems to work, but very unreliably. -- "In the old days, writers used to sit in front of a typewriter and stare out of the window. Nowadays, because of the marvels of convergent technology, the thing you type on and the window you stare out of are now the same thing.” -- Douglas Adams -- https://mail.python.org/mailman/listinfo/python-list
IDLE editor suggestion.
Maybe this already exists but I have never seen it in any editor that I have used. It would be nice to have a pull-down text box that lists all of the searches I have used during this session. It would make editing a lot easier if I could select the previous searches rather than having to enter it every time. If this is inappropriate to post this here, please tell me where to go. Life should be so complicated. -- https://mail.python.org/mailman/listinfo/python-list
RE: A problem with str VS int.
With all these suggestions on
how to fix it, no one seems to
answer why it fails only when
entering a two-digit number.
One and three work fine when
comparing with str values. It
is interesting that the
leading 0 on a two digit
worked. Still, one digit and
three digit work but not two.
This is now more of a
curiosity as I did use the
integer comparisons.
SGA
-Original Message-
From: Python-list
On
Behalf Of dn via Python-list
Sent: Sunday, December 10,
2023 12:53 AM
To: python-list@python.org
Subject: Re: A problem with
str VS int.
On 10/12/23 15:42, Steve GS
via Python-list wrote:
> If I enter a one-digit
input or a three-digit number,
the code works but if I enter
a two digit number, the if
statement fails and the else
condition prevails.
>
> tsReading = input("
Enter the " + Brand + " test
strip reading: ")
> if tsReading == "":
tsReading = "0"
> print(tsReading)
> if ((tsReading <
"400") and (tsReading >=
"0")):
> tsDose =
GetDose(sReading)
> print(tsReading
+ "-" + tsDose)
> ValueFailed =
False
> else:
> print("Enter
valid sensor test strip
Reading.")
>
> I converted the variable to
int along with the if
statement comparison and it
works as expected.
> See if it fails for you...
It works as expected (by
Python)! This is how strings
are compared - which is not
the same as the
apparently-equivalent numeric
comparison.
Think about what you expect
from the code below, and then
take it for a spin (of mental
agility):
values = [ 333, 33, 3, 222,
22, 2, 111, 11, 1, ] print(
sorted( values ) ) strings = [
"333", "33", "3", "222", "22",
"2", "111", "11", "1", ]
print( sorted( strings ) )
The application's data appears
numeric (GetDose() decides!).
Accordingly, treat it so by
wrapping int() or float()
within a try-except (and
adjusting thereafter...).
"But wait, there's more!"
(assuming implement as-above):
if 0 <= ts_reading < 400:
1 consistent 'direction' of
the comparisons = readability
2 able to "chain" the
comparisons = convenience
3 identifier is
PEP-008-compliant = quality
and style
--
Regards,
=dn
--
https://mail.python.org/mailma
n/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
