31–40 of 68 posts
It seems like a generator like @Signature(...input types, output type) would solve this problem with limited language changes, and would work in python 2/3?
Has anyone ever tried to implement optional typing in python with just generators? It seems like a generator like @Signature(...input types, output type) would solve this problem with limited language changes, and would work in python 2/3?
With type annotations you can have static guarantees, which decorators will not be able to provide, as decorator methods will be called and resolved only during runtime. Objects imported from `types` hopefully will not.
Has anyone ever tried to implement optional typing in python with just generators? It seems like a generator like @Signature(...input types, output type) would solve this problem with limited language changes, and would work in python 2/3?
The main advantage of static typing to me is that it enables automatic refactorings. Without types, it's impossible for tools to refactor your code safely without the supervision of a human. This leads to developers being afraid of refactoring and, ultimately, code bases rot and become huge piles of spaghetti that nobody wants to touch. With a statically typed language, I'm never afraid to refactor whenever I see an…
I haven't done large-scale refactoring work before. How does typing help with refactoring? Is it because you know exactly what's being passed into a function?
Has anyone ever tried to implement optional typing in python with just generators? It seems like a generator like @Signature(...input types, output type) would solve this problem with limited language changes, and would work in python 2/3?
Do you mean decorators? A solution like that exists and has been used for a while. It really is only usable for run-time type-checks. See here: https://github.com/dobarkod/typedecorator With type annotations you can have static guarantees, which decorators will not be able to provide, as decorator methods will be called and resolved only during runtime. Objects imported from `types` hopefully will not.
https://github.com/dobarkod/typedecorator is interesting -- I was imagining type signatures more like haskell's:
addNumber :: Int -> Int -> Int
@TypeSignature([int, int, int])
def add_number(a,b):
....
; (> SECRET GUESS)
;
; caught WARNING:
; Derived type of GUESS is
; (VALUES STRING &OPTIONAL),
; conflicting with its asserted type
; REAL.
; See also:
; The SBCL Manual, Node "Handling of Types"
;
; compilation unit finished
; caught 1 WARNING condition
; printed 8 notes
The main advantage of static typing to me is that it enables automatic refactorings. Without types, it's impossible for tools to refactor your code safely without the supervision of a human. This leads to developers being afraid of refactoring and, ultimately, code bases rot and become huge piles of spaghetti that nobody wants to touch. With a statically typed language, I'm never afraid to refactor whenever I see an…
I hear this argument a lot, and I'm sure static typing is helpful when refactoring, but I have found that nothing is as important as tests when refactoring. I'd rather refactor dynamically typed code with good test coverage than statically typed code without good tests.
Especially in the prototyping phase, I do a lot of iterating and refactoring - and I mean A LOT, because I've found that this is the best way for a good design to fall out. Sometimes like 20-30% of the code get refactored, replacing core data structures and control flow.
If I ever had to rely on unit tests for this, I'd shoot myself, mainly because it would make me 1/2 times slower (because I'd have to reimplement all unit tests every time) and this would really break my flow.
Also, relying on unit tests for refactoring means that having anything short of 100% code coverage (i.e. 70-80% isn't enough) defeats the purpose of the whole thing anyway - and I've yet to see 100% test coverage in a real-world project. I realize this isn't an argument in the context of your reply (it was either test coverage or static types), but still, something to consider.
Ugh. I have hardly any type problems in my Ruby code. I've gotten very good at recognizing implicit state and capturing it in a properly instantiated object with a well-named class. I daresay that if you don't have this skill, a type system isn't going to help you much and you're going to get nasty bugs anyway. The problem in Ruby is nils, and you'd have the same problem with the same solution in a static language; c…
Ugh. I have hardly any type problems in my Ruby code. I've gotten very good at recognizing implicit state and capturing it in a properly instantiated object with a well-named class. I daresay that if you don't have this skill, a type system isn't going to help you much and you're going to get nasty bugs anyway. The problem in Ruby is nils, and you'd have the same problem with the same solution in a static language; c…
A good type system doesn't allow you to call impure code from a pure function. It just won't compile. So your skill becomes useless because it's automatically verified by the compiler.