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 pyt...@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....@python.org> On Behalf Of Python Sent: Wednesday, January 25, 2023 10:06 PM To: python-list@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.gr...@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 -- https://mail.python.org/mailman/listinfo/python-list