bool and int

[avi.e.gross at gmail.com]

Like Chris, I appreciate precision when it matters but since I am not
writing a textbook here, I often talk more informally.

There are many variations on now variables or objects are treated
differently in certain languages and when I said "STRONG" I simply meant a
sort of opposite to "WEAK". I could have used any number of silly words like
"mighty typing" and most would have been meaningless.

As python at bladeshadow.org points out, from some perspectives, Python plays
quite fast and lose about what a variable can refer to. It is not a bug but
a proud feature of the language that you can easily do all kinds of things
with a kind of polymorphism (and I do NOT want to hear how I misused that
term in some technical way).

I have been reading about the ways Python keeps amending the ways you can
tell a program about the types a variable can hold and it gets quite amusing
in some ways. First, almost anything you write has to be IGNORED at
run-time. You are sort of just slowing down things and making your program
text longer, albeit the byte-compiled files may toss much of that. The main
purpose if of static type checkers like mpy to badger you until you come up
with just the right incantation and even then, your program can have plenty
of bugs and fail at run-time. There is a rich and seemingly ever-growing new
set of quasi-language features for specifying more closely what a function
expects as arguments and what it might return and some are potentially very
useful except for the minor detail that at runtime, your suggestion that
your function takes only objects that implement some protocol such as
defining __lt__  is absolutely ignored. All that mpy can do is static
testing of what you CLAIM you want. 

I am not making fun, of course, but in code I develop, I have negligible
interest in using the optional typing system and checking at first. It can
truly slow things down and some of the constraints can turn out to be too
tight if you later find the method you used excludes lots of things people
would use it on. I prefer having working code before I mark it up to be less
legible but in a way that finds some possible errors, or maybe mainly forces
me to change the markup to something else. And, if I really want my code to
CATCH errors when running, the beginning of many functions will have to
contain active tests such as checking if it is one of the types I want it to
support or implements some protocol, and if not, handle the error
gracefully. Such code can be way more detailed or correct than the type
system or may be way worse but it can also in some sense be a
self-documentation that some can read easier than trying to enforce strong
typing.

If I was working on a large project with many people and the organization
had all kinds of protocols and rules, then sure, you follow them or leave.
But at some point you may ask the dumb question of why they are using Python
at all, rather than a much "safer" language designed to minimize any ability
to make many errors as the program refuses to run until highly polished?


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com at python.org> On
Behalf Of Python
Sent: Wednesday, January 25, 2023 10:06 PM
To: python-list at python.org
Subject: Re: bool and int

On Wed, Jan 25, 2023 at 01:01:24PM +1100, Chris Angelico wrote:
> On Wed, 25 Jan 2023 at 12:43, <avi.e.gross at gmail.com> wrote:
> > Python has a different philosophy than some other languages with 
> > strong typing. In some of those, you would not be allowed to add or 
> > multiply at random but would need to convert parts of your 
> > calculation to all be the same, such as a 32-bit integer. You could 
> > still do things like I mention above but only after consciously 
> > mapping your Boolean to an actual zero or one of the kind wanted.
> 
> Python is strongly dynamically typed. You may be thinking of "static 
> typing" rather than "strong typing" here,

You often insist on this but frankly it does not jibe with the definitions
of "strongly typed language" that I was taught or that I still see used
commonly, including in literature and on sites that aim to teach people
about computer science, which basically amount to:

1. A language whose variables are defined by type, and can only hold
   that type, typically but not necessarily compiled.
2. A language which strongly enforces restrictions on mixing or
   operating on, and/or implicitly converting different data types,
   with the implication that the structure of types is well-defined
   and rigid.

Python conforms to neither--its VARIABLES are normally untyped (though the
object data they hold obviously is).  Object instances can have new fields
added to them on the fly, willy-nilly, and Python allows for any object
which has an interface--or rather only the portion of interface you care
about in the moment--like the one it expects, to be used in a given context,
i.e. duck typing.  Useful properties (when used carefully!) but not
intuitively consistent with the idea of "strong typing" and potentially
dangerous if care is not taken.  When YOU say that Python is strongly typed,
you're using some other definition--one that is perhaps technically correct,
but seemingly quite a lot of people in the field--including active students,
college professors, and seasoned professionsals--are unaware of...

The above usages are common and widespread, widely accepted--which is
inherently what makes word usages correct--and you very obviously know full
well what people mean when they use them; so "correcting" people who use
them seems rather unhelpful (certainly without detailing what you think it
means), inappropriate, and arguably just simply wrong.
It seems to serve no purpose other than to make communication harder, and
possibly to irritate people.  I would encourage you to consider ceasing the
practice, so as to not needlessly detract from the otherwise usually good
info you routinely provide...

And FWIW if you want some references, a google search will return voluminous
examples of people using the term as I described--from acadamia to
business--but here are just a few: 

https://www.cs.cornell.edu/courses/cs1130/2012sp/1130selfpaced/module1/modul
e1part4/strongtyping.html
https://courses.yarrahills.vic.edu.au/moodle/mod/book/view.php?id=18778&chap
terid=28
https://www.oreilly.com/library/view/mastering-c-and/9781785884375/ch02s02.h
tml
https://www.postgresql.org/docs/current/typeconv-overview.html
https://www.sciencedirect.com/topics/computer-science/strongly-typed-languag
e
https://www.techtarget.com/whatis/definition/strongly-typed

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