6 ms·
One of the reasons why I use Python 3.x exclusively is for the new function annotations, which allow use of this: https://github.com/prechelt/typecheck-decorato
by bkeroack 11y ago
One of the reasons why I use Python 3.x exclusively is for the new function annotations, which allow use of this: https://github.com/prechelt/typecheck-decorator https://github.com/prechelt/typecheck-decorator
This allows me to write Python in a design-by-contract style with full, rich runtime type checks. My bug count has gone down dramatically, and when I do find a bug it's virtually always via a typecheck exception.
- reeboo 11y agoYeah, isn't that amazing? I really think this "type" idea is a good one. I wonder if other languages have thought about following Python's lead and adding a type system.
- rattray 11y agoWould you like to reconsider your tone?
- reeboo 11y agoNo, but let me clarify. Bolting on a form of type checking to a weakly typed language seems orthogonal to the nature of a language like Python. If you find yourself saying "I wish I had a type system in this code base, its getting pretty big and a compiler that does type checking at compile time sure would make my life easier" maybe you should think about using a more appropriate tool. I use Python a lot and it has its uses, but adding this type hint stuff just seems like an enabler for causing myself pain and denial when I should be using a more strongly typed language.
- swhipple 11y agoStatic typing is considered unpythonic, but the typecheck library is closer to a sanity-checking model (like using assert). The advantage is that instead of the checks being in the body, they can be moved to the function header. It supports things such as checking ranges or regex matches, rather than just object types. Even if people are only using it as a shim for what could be static typechecking, I think there's something to say about the practicality of it existing, if only for the reason that their ecosystem might already be Python-based.
- dangirsh 11y agoThough I agree with your sentiment, I must mention that there is nothing "weak" about Python's type system. You likely meant "dynamic", not "weak". See here: wiki.python.org/moin/Why%20is%20Python%20a%20dynamic%20language%20and%20also%20a%20strongly%20typed%20language
- aapycgarb 11y agoPython's type system is weak whether they self-identify that way or not. Types are implicitly converted in a variety of cases, notably True-ness. Meanwhile, runtime type identity is kind of meaningless; classes and individual objects can have their behavior meaningfully changed at runtime. The most you can say about any variable in Python is that it is a descendant of 'object' or else some primitive type.
- Veedrac 11y agoIf Python's `if` is weakly typed, then Rust's `for` and `.` are weakly typed. Few would say that, though.
- cma 11y agoOne place where Python is pretty weakly typed is going the other way, where it accepts things like: true + true * 2 - false / true, even outside of if statements. I've definitely been bitten by this before, accidentally passing in a book parameter instead of an int, and having some math work initially and then blow up months later. Knuth argues against this kind of implicit bool to integer conversion in Concrete Mathematics.
- ubernostrum 11y agoNitpick: this isn't an implicit conversion. There's a lot of history of languages without a real boolean type using integer 0 and 1 as the sentinel values indicating false-ness and true-ness. And Python, in a nod to that, implements bool as a subclass of int, of which only two instances can ever exist (with False having a value of 0 and True having a value of 1). So this isn't weak typing -- isinstance(True, int) is True in Python, and operations like the ones you're mentioning work because of that, for the same reason any other subclass of int would work.
- rattray 11y agoI agree with everything you said here. Personally, I wish this had been your original post. It seems like a helpful jumping-off point for constructive conversation.
- Sir_Substance 11y agoWow, he used sarcasm to make a point that was both humorous and relevant, and you're reacting like an imam hearing a joke about muhammad. Maybe you should reconsider yours?
- rnnr 11y agoYeah, imagine how retarded the type systems of the popular static typed languages were, that lead to such a baby-booming of dynamic languages. People were traumatized so hard that took years to reconsider a middle ground.
- rtpg 11y agoI think it's always been about how annoying it is to write out types. If you look at how popular go is among pythonistas, it kind of shows that the issue was really a lack of type inference more than anything else.
- rnnr 11y agoI share the same opinion, even sth as simple as TI makes things so much better. It's not only about writing but also reading the code. A good summary what's wrong with the type systems of the java era: http://www.slideshare.net/ScottWlaschin/c-light http://www.slideshare.net/ScottWlaschin/c-light
- rtpg 11y agowhat a great presentation, very powerful stuff
- reeboo 11y agoThat's an interesting way of looking at it.
- rurban 11y ago> Following Python's lead and adding a type system Joking? Python really is almost the last of all dynamic languages to come up with syntax for that. common lisp, scheme, perl, ruby, javascript, php have all syntax for optional typing already, only Guido was against it for years. Which eventually led to Go being developed by Google, and python's downfall. They try to catchup now, but this proposal is only 10% of an optional type system. I miss the inferencer and the optimizations still.
- ak217 11y agoThanks for the link. I developed the annotation+decorator-based type checker in https://github.com/kislyuk/ensure https://github.com/kislyuk/ensure before I saw typecheck-decorator (which looks like it has some cool features). One thing I'm proud of with ensure's @ensure_annotations decorator is that we actually went through a few rounds of optimization and are fairly confident in the decorator's runtime performance. Optional type checking as a first-class citizen is a great tool to have, and it's good to see the syntax standardized. But as alluded to in the Reddit thread, there are serious issues with this PEP. The use of comments and the lack of runtime type checking from the start not only limits the potential of this particular PEP, but undermines future efforts to bring that functionality in. IMO it would have been better to put in the work and properly integrate type checking decorations into the interpreter and the grammar. The tack-on comments at the end of the line are especially un-Pythonic and jarring. Edit: Just saw the string literal based forward references. Ugh. Another problem in the making.
- true_religion 11y agoThis might sound odd, but lately I haven't noticed any bugs I've introduced to production that were type errors. Inevitably my code will produce results of the right type, but have a logical error that makes either the answer flat out wrong or more or less inaccurate based on our cloud requirements.
- codygman 11y agoYou can encode logic into types making what were previous runtime logic errors compile time errors.
- Veedrac 11y agoYou can in some languages, but it's not so easy with dynamic, surface-level type checks.
- alextgordon 11y agoAh but type annotations allow tools like QuickCheck to exist, so you can automatically catch those logic errors too!
- drincruz 11y agoI can see this being very useful. Runtime type checking, a contract for code to follow; all should help out with better code quality.