Python. Oh dear Python. Why, oh why, when I have your function with parameters defined as an int, do you blithely accept a string and just go about your merry day? If I wanted you to be able to accept a string I would have let you accept a string. But no, I want ints. Its not a suggestion. Its a demand.

You're dynamically-typed thug life gets on my static-typed backgrounds nerves.

(I am fully aware of the reasons for it and why, but my goodness I do sometimes miss my static-typed compile error languages, rather than pseudocode that accidently compiles python)

Duck Typing stares at you intensely...

@Demolishun when you stare at duck typing.....duck typing stares back at you

OP where you using type hints? just kidding it doesn't matter, becuse for example you can have a function that takes a specified valueI:int, but if you use that item in the context of the string, and still pass a string it will work, BUT if you pass an int as originally define it will give you shit

example

@highlight
def lolthisisBs(valueInt:int) -> string:
return "Lol " + valueInt
#works
lolthisisBs("not a number")
#does not work
lolthisisBs(1)

@AleCx04

:shakes fist at the sky of Pythonic values:

@lynkfox I lean don't get me wrong. I love Python, but these the kind of errors I introduce on account of me being a dumbass that relies far too much on languages with proper type systems.

What were you doing that it passed a string to it?

@AleCx04

Same thing here - I find I actually enjoy Python a lot.

but it was a simple formatting function, and I 'knew' i was getting 0/1 in a dictionary being passed to me, and it will either need to be True/False or None/Yes (depending on the field). If neither 0/1 return the value so I was confused why the heck my integration tests were showing assert "1" == "True" - using a full response dict not my stubs.

and then I realized the dictionary was storing it as strings.

Ah python. Ah my assumptions and my idiocy :grin:

Yeah , this kind of crappy typing is why I hate using it. If it was strongly and statically typed, then I'd be very interested.

Because there's no static typing in python. All type hints are just for the separate checker and they do nothing in runtime.

Yeah, it's really all just type "hints" there's nothing set at stone... whatever type checking there is you might as well pretend it's not there at all!

Type hints are great but that's all they are: hints

if static types are laws then type hints are subtle social cues

Python is made by a dutch dude. We accept a lot. It's part of our culture. You can pass a string while an int is declared. That's freedom young man! :)

Seriously: recently a 3rd party lib forced me to use a set() instead of a tuple because of this shit. It was pydantic if i remember correctly.

OT; python is as a girlfriend. You respect it, but sometimes it lets you do whatever you want for the sake of love (L)

:D

@AlmondSauce amusingly I don't mind weakly typed nearly as much. Var in c# makes things much easier to read

MyClass instance = new MyClass() is just so much more clunky than

var name = new MyClass() and in general the idea of a variable being free to be anything until it's something I'm 100% fine with...

But the fact that you don't compile python and it just runs - and sometimes just is able to run even when you think it shouldnt... o.o

@Hazarth hah! I love that metaphor.

It also flies well with the annoyance that with type hints you still have to account for a bunch of abuse cases (like with social cues its easy to read wrong) but with static typing nope. It's a string or we throw everyone I jail!

@lynkfox It *looks* nicer, but that's an area of C# I really don't like. Java has implemented the same keyword but kept the strong typing - var just denotes the type is inferred rather than decided at runtime. Makes the code neater and keeps the static type system.

@AlmondSauce var does that exact same functionality in c# - infered. i.e. weak typing.

The somewhat recent Dynamic keyword however is a dynamically assigned variable that can change its type during run time, and has since turned c# into being able to act as a dynamically typed language... to my dismay, but at least the rest still functions as a static typed language.

@lynkfox weak typing is not equal to dynamic typing. Python has dynamic, not weak one.

@lynkfox inferred static type is not anywhere near weak typing. Gosh! I'm so triggered. Do you even know what different typing types are?

@iiii gosh your so triggered that you read my rant wrong!

Yes. Python is dynamic and I was ranting that its not static (note the at compile time line)

Python is also duck typeing. Which is often mistaken as weak, but is not so. It's just a freedom to use variables as other types based on their inherent methods that can be used in other variable types.

But I never once claimed python was weak typed - its variables are a specific type, but with duck typing it can auto cast them as needed.

I did note that Var keyword in C# gives it an aspect of weak typing (inferred) and the Dynamic keyword (again in c#) gives it at run time variable assignment, which is not static as the language usually is.

This comment was in reference that weak typing doesn't bother me as much as dynamic does - a static weak type language (C maybe if you're literal about Pointers) doesnt annoy me nearly as much as any dynamic (run time decided) language

@iiii The rant itself was about missing my compile time errors that don't happen in Python.

The comments went on to talk about weak and strong and how I find weak less of a problem - and thar C# has implemented two keywords to give it pseudo weak typing ( var ) and run time allocation of type (dynamic) - yes yes, fine maybe the way c# and Java actually implemented var is not really weak - but the point is the same.

Plus weak/strong is so miss-used now that what it actually means is muddied. C is often called weak (as I pointed out with pointers... heh ) because you can cast without errors but it's also got strong typeing at times, where you can't do that.

But by other definitions of weak, where there is no keep track of what kind of variable it is in memory, it's purely weak and even the 'weak' typing of c#/Java in var isn't- its just pseudo weak.

All this is me going on that: yes, static/dynamic is clear. Weak/strong is not, and easily conflated... but I did not conflate them.

@lynkfox I was not speaking of the rant itself but the comments where you said that "var" is C# is dynamic and that type coercion is dynamic.

@iiii I specifically said var is not dynamic, but close to weak. (Pseudo weak)

Dynamic keyword is dynamic

@lynkfox it's not weak, nor dynamic. It's static and strong.

@iiii and my entire point in the second set of comments was that Strong/weak is so badly defined that its mistaken.

Some defined examples

https://dotnet-guide.com/what-is-th...

Some opinion

https://google.com/amp/s/...

Some more opinion

https://social.msdn.microsoft.com/F...

And my favorite

https://docs.microsoft.com/en-us/...

Where it specially calls out: C# 4.0 has features that make it both dynamic and static, as well as both weakly and strongly typed.

@iiii main point I'm making here: static VS dynamic is easily defined (run time allocation of type VS compile time)

Strong and weak are not as there are close to a dozen definitions of what these mean. It's been too muddied.

And more so, as C# grows they are adding weak and dynamic abilities to the language that started strong and static to grow its ability to handle certain situations where such things are advantageous.

But hey. I've ranted on my rant on your rant long enough. If you choose to think I'm wacked, then none of this will change your mind. I am well aware of the differences of the 4 quadrants of typing in languages and comfortable with my understanding of what is and isn't one of those 4 quads, and my knowledge thar c# is deliberately adding features that place it in all 4 quadrants