Why do people think Python is ducktyped? The syntax is quite explicit, just because x = 5. is shorthand for x = float(5) doesn’t mean it’s doing weird mutations. The closest would be maybe that something like:
x = 5y = 2.
z = x * y
works (I think) but that’s not exactly a wacky behaviour. It’s not like it ever does the wrong behaviour of casting a float to an int which can erase meaningful data and cause unpredictable behaviour.
I mean you can (and often should!) give functions/methods type signatures ffs.
Because to a certain extent Python is duck typed. Python has no concept of interfaces, unless you count the abc module combined with manual isinstance() checks, which I’ve never seen anyone do in production. In order to be passed to some function that expects a “file-like object”, it just has to have methods named read(), seek(), and possibly isatty(). The Python philosophy, at least as I see it, is “as long as it has methods named walk() and quack(), it’s close enough to a duck for me to treat it as one”.
Duck typing is distinct from weak type systems, though.
In my head I had conflated duck and weak typing. I’m not an oop programmer (tbh I’m not much of a programmer to begin with) and since what Python does e.g. with file handles is closer to say in Haskell making a wrapper
DataStream x -> FileHandle x
Where like implementing the read/write/open etc methods are equivalent to implementing the function mappings.
Which is very different from say JS “Herr durr I’m going to cast an int to a string and then error” I assumed the latter was “duck typing”
Why do people think Python is ducktyped? The syntax is quite explicit, just because
x = 5.
is shorthand forx = float(5)
doesn’t mean it’s doing weird mutations. The closest would be maybe that something like:x = 5 y = 2. z = x * y
works (I think) but that’s not exactly a wacky behaviour. It’s not like it ever does the wrong behaviour of casting a float to an int which can erase meaningful data and cause unpredictable behaviour.
I mean you can (and often should!) give functions/methods type signatures ffs.
Because to a certain extent Python is duck typed. Python has no concept of interfaces, unless you count the
abc
module combined with manualisinstance()
checks, which I’ve never seen anyone do in production. In order to be passed to some function that expects a “file-like object”, it just has to have methods namedread()
,seek()
, and possiblyisatty()
. The Python philosophy, at least as I see it, is “as long as it has methods namedwalk()
andquack()
, it’s close enough to a duck for me to treat it as one”.Duck typing is distinct from weak type systems, though.
Yeah I guess I should think before I say shit.
You’re right.
Thank you for acknowledging that. I’d also like to say for the record that you were literally one word off from being correct.
In my head I had conflated duck and weak typing. I’m not an oop programmer (tbh I’m not much of a programmer to begin with) and since what Python does e.g. with file handles is closer to say in Haskell making a wrapper
DataStream x -> FileHandle x
Where like implementing the read/write/open etc methods are equivalent to implementing the function mappings.
Which is very different from say JS “Herr durr I’m going to cast an int to a string and then error” I assumed the latter was “duck typing”
Python has Interfaces in the form of protocols, but those are explicitly duck-typed