> It would be interesting to read your take on the engineering problems involved, the design tradeoffs self - the reason is that I forget to type it and causes

> It would be interesting to read your take on the engineering problems involved, the design tradeoffs self - the reason is that I forget to type it and causes me to go back and fix the method signature or method call (there are usually lots of them in the code, so lots of opportunities to forget self - hence lots of instances where it can be omitted so that it must be fixed, at least for me; the remark is a gripe about ergonomics of syntax) The alternative: do a different keyword for method definitions other than def; (well, still you need something to differentiate between method invocation and global function call in an untyped language) : at the end of function definition or a block - same thing. KeyError if dict entry not found; most other languages I know would return None, so that's counter intuitive to me (I know about get, but [ ] is the default syntax for accessing dictionaries in most languages) I know it will cause an undefined method call to bomb, which is a good thing in my book; but I don't like it for data structure access - I also don't like exception handling in particular and prefer explicit checking of results (again matter of taste and habit + frequent cause to go back and fix it) I think python is making several tradeoffs in favor of making the resulting script more robust (like going for exception handling) but it makes the experience of writing said script a bit more tricky.