3 ms·

If that is the case, why not use Pythons's optional type annotations? Since the author didn't consider that, I suspect this is more about a love story than a to

If that is the case, why not use Pythons's optional type annotations? Since the author didn't consider that, I suspect this is more about a love story than a tool evaluation. Rust my new love, I'm breaking up with Python. > Years of coding in Go gave me this comfortable feeling: if it compiles, it works. That is never a rational feeling. > Type hints solve these issues to some extent, but bugs can still slip through. But the link is to a tweet showing how a Python static analysis tool actually caught the bug. > You could set up CI/CD pipeline enforcing 100% code coverage, but that will affect team productivity and surely piss off people. If enforcing optional type hints would piss people off then, surely, using a statically typed language would also piss people off.

maldev 4y ago
You're 100% right, the new type annotations are really nice to. You can still be really pythonic and leverage some cool reflection capabilities with types. And on your point of forcing people to use types. I can't imagine many situations where you don't have a type in mind and can't use a higher order function to solve the problem. Which python does internally with __add__ __str__ and all the other functions included with classes. As an example of stuff you can do with types. I was trying to teach a buddy how to program from a non CS background and I explored it a bit to make it as modular as possible so he could literally just change the structure and types and the code would all work for him. And it's really easy using some reflection For example, to mimic a struct, you can use. @dataclass class CSVStruct: x: int = 0 y: int = 0 foo: int = 0 bar: int = 0 Then you can typecast dynamically and generate random data(assuming you can go from int -> datatype) to fille in the data. arg_list = [] # Generating argument list dynamically for field in dataclasses.fields(self.CSVStruct): arg_list.append(field.type(randint(0, 100))) Or to get all the names of a struct (In this case to print out any structure with headers into a CSV file. Can also be done with their values) # Getting column names row_names = {field.name: field.type for field in dataclasses.fields(self.CSVStruct)}

maldev 4y ago

You're 100% right, the new type annotations are really nice to. You can still be really pythonic and leverage some cool reflection capabilities with types. And on your point of forcing people to use types. I can't imagine many situations where you don't have a type in mind and can't use a higher order function to solve the problem. Which python does internally with __add__ __str__ and all the other functions included with classes. As an example of stuff you can do with types. I was trying to teach a buddy how to program from a non CS background and I explored it a bit to make it as modular as possible so he could literally just change the structure and types and the code would all work for him. And it's really easy using some reflection For example, to mimic a struct, you can use. @dataclass class CSVStruct: x: int = 0 y: int = 0 foo: int = 0 bar: int = 0 Then you can typecast dynamically and generate random data(assuming you can go from int -> datatype) to fille in the data. arg_list = [] # Generating argument list dynamically for field in dataclasses.fields(self.CSVStruct): arg_list.append(field.type(randint(0, 100))) Or to get all the names of a struct (In this case to print out any structure with headers into a CSV file. Can also be done with their values) # Getting column names row_names = {field.name: field.type for field in dataclasses.fields(self.CSVStruct)}