Differentiating properties and methods from internal methods is as simple as using another char, like dots and colons. So box.length would not be the same as box:length, that way you could assign all names you want without fear of collision. Poor choices in language design will always haunt you til the end of times.<p>That being said, python is my favorite language right now and the only complain I have is about underscores which I try to avoid.<p>Now, GO being a new language, I can't really understand why it does not implement methods for primitive types like "hello".ToUpper(), instead we have to import "strings" and call strings.ToUpper("hello").<p>Easier for the compiler but harder for the programmer has never been my mantra.
So... Python has len() because it would be too hard to standardize on .len(). Any by the way, len() calls .__len__(), on which we have standardized.<p>Got it.
It's a bit dated, but the Python Cookbook does a great job of teaching you practical examples of Python if you already know other languages and want to quickly grok what is "pythonic." It starts with string crunching and hits just about every other general sysadmin use case, covering most of the standard library along the way.
The goal in language design is not "least astonishment" but inferability. And, while Python may not meet the least astonishment goal for new users coming from another language, Python is remarkably inferable and internally consistent.
For extra fun....<p><pre><code> a = 5
def print_a():
print a
# Prints 5
print_a()
def print_and_assign_a():
print a
a = 2
# raises UnboundLocalError
print_and_assign_a()
class PrintOnInitSet(set):
def __init__(self, *args, **kwargs):
print "init!"
set.__init__(self, *args, **kwargs)
# Creates a PrintOnInitSet and prints "init!"
a = PrintOnInitSet([1,2])
# Creates a PrintOnInitSet and prints "init!"
b = PrintOnInitSet([3,4])
# Creates a PrintOnInitSet and prints nothing
c = a | b</code></pre>
Overall it's a good article, but I don't fully understand his complaint about decorators, and I think he may not understand them. @foo and @foo() intentionally mean very different things. I don't see how you could "add a parameter to a previously parameter-less decorator" without drastically changing the meaning of the whole thing.<p>They may be tricky to wrap your head around, but there's nothing too surprising about decorators.
This is a nice article, as a non-Python programmer who's dabbled a bit in order to read some random Python code, it gave me some appreciation for the "Pythonic"-way.<p>I have to say though, that the thing that astonished me the most about Python is the Java-like "closures". I sort of thought it would be like Ruby, which I thought was closer to Scheme and JavaScript, and then I realized that Ruby isn't quite like them either. (I know Ruby is close with its lambdas and blocks, but it's not intuitive to me.)<p>This isn't necessarily to the detriment of Python (or Ruby) but just something I observed when trying to explain Java's lack of closures to someone who only knows Python.
"I was quite fond of Raymond Hettinger's talk about what makes Python unique because he showed a bunch of small examples that almost exclusively used the good parts of the standard library and hardly any user written logic."<p>Is this talk available anywhere?
I miss something like the Principle of Least Astonishment for design.<p>Why every time there's a revamp of a website the new design is more astonishing and less clear? Why the search button in Google Calendar is now blue?<p>Why new design is usually a tease on our muscle memory?