Questions on "Python Is Not Java" [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center. Closed 11 years ago.

I'm a novice programmer with basic Java experience, and currently learning Python. I've stumbled across this blog post in another question thread:

http://dirtsimple.org/2004/12/python-is-not-java.html

and I've got a couple of questions regarding the topic posted:

---

1) "Oh, and all those Foo.Bar.Baz attribute chains don't come for free, ... , so each dot counts. "

Is the solution to this particular problem is importing module and its method beforehand? Such as:

       from Foo.Bar import Baz
       ...
       #now Baz() can be called directly without using Foo.Bar.Baz() ever开发者_高级运维ytime

---

2) Got a switch statement? The Python translation is a hash table, not a bunch of if-then statments.

There are several related answers regarding this topic, but they also raise a couple of questions:

1. Use of if-else is cleaner, but it doesn't have the advantage of constant time O(1) in switch statement.
2. Use of hash for constant time O(1)
3. Use of lambda function in hash for comparison (not recommended)
   • Why is it not recommended? Is it because the lambda function removes the constant factor of hash?
4. Use of bisect module
   • Does this method retain the constant time O(1), or it is just another type of lambda function?
   • So what method in Python, that is equal to switch statement, with constant time O(1), while at the same time allowing comparison statement?

---

3) Getters and setters are evil. Evil, evil...don't write getters and setters ... This is what the 'property' built-in is for ... In Python, this (getter and setter) is silly, because you can start with a normal attribute and change your mind at any time, without affecting any clients of the class.

I don't really quite understand this part.

Also, it seems that in Python public and private method or variable can be easily accessed, in contrast of that in C++ and Java. Is there any design reason for this behavior?

---

Finally, is there any recommended further good read on Python vs. any other programming language?

---

1. It rarely matters. If it does, you'd be better off writing C (or letting Cython do that for you, with static type annotations to make it really count), using PyPy (their JIT can completely remove such lookups and many more things, even memory allocations, in certain loops), etc.
2. "lambda" is in a different category than "if-elif chain" or "bisect". What technique are you referring to specifically? Many dislike lambda as they consider it relatively verbose or unreadable (at least some of its uses can become this quickly). bisect is just maitaining an ordered list, so the best lookup you get is O(log N) binary search. You want a switch statement? Use dicts. Comparisions (apart from ==, of course) are outside the scope of switch and most things commonly compared to them and make O(1) lookup impossible anyway.
3. What about it isn't understandable? When you write Python, you don't write getter or setter methods. You use normal attributes. If you later see that you need some further logic upon attribute access/modification, you turn it into a property and all code using it can run on without changes.
4. As for the absence of real privacy - this has been asked and answered many times, the short answer is that "we're all adults in here", i.e. programmers are trusted not to fiddle with private things unless they have a very good reason. Another, weaker reason is that this is hard to implement in a dynamic language, at least with the current object model (where methods are just normal functions, for instance).

---

1. Often an answer is to use local names (variables) which refer to the specific object instance in question (in the scope of your loop, for example). Python's late-binding dynamic semantics require its interpreter to walk through every "." reference every time because the objects to which each of these is bound may have been changed by previous iterations through our loop. As with most other comments about performance this doesn't make much difference until you're operating on a large scale (millions of loop iterations multiplied by several layers of "." dereferences)

2. Sometimes the better approach is to re-think your design and use "smarter" objects. Frequently switch/case statements are used to implement different behavior within one class of objects where one could implement a number of related classes, each of which "do the right thing" based on their own type. Other times, as the commentary suggests, you're going to create a dictionary ("hash") of keys and objects (functions, instances, lambdas, whatever) and use it as a dispatch table.

3. Python allows you to access attributes directly (without getter/setter methods) and, if you need to do so, you can use properties to ensure that your own code (getter/setter) is executed implicitly. Users of your code don't have to know or care whather foo.bar=1 is directly binding a new value to foo's bar attribute or whether it's calling a method of foo which is performing some international state manipulation that would be visible by accessing foo.bar later. Those are implementation details. Having the language encourage programmers to implement all object/attribute references as explicit ".get()" and ".set()" calls while still supporting simpler "." syntax confers not benefit to the code; it just makes the code more cluttered and harder to read.

Yes, attributes and methods can be easily accessed and "hiding" them is difficult. It makes the language easier to use. (The counter argument that it makes classes easier to "abuse" --- that is that it allows users to access implementation details of a class which aren't intended to be public ... it doesn't force them to respect the intended abstractions. That's a moot point. If your class documents the intended interface and implements them reasonably then those are the interfaces which most programmers will use. If they feel the need to muck around with your implementation details you probably did it wrong --- and their alternative is to just re-implement whatever you did to work around the limitations you imposed).

---

1. Maybe. It isn't always feasible (or possible) to do specific imports in this manner.

2. Lambda functions are dissuaded for the normal reasons lambda functions are dissuaded (not all of which I agree with). bisect is a binary search, so it's O(log N).

3. "Recovery from Addiction"