We Keep Coding

Class Members -- Java vs. Python

I am coming from Java and learning Python, now. I try to understand the concept of class members in Python.
Here is an example program in Java:
class Hello {
int x = 0;
void ex() {
x = 7;
}
public static void main(String args[]) {
Hello h = new Hello();
System.out.println(h.x);
h.ex();
System.out.println(h.x);
} }
That is what I did in Python, following some examples I found:
class Hello:
def __init__(self) :
self.x = 0
def ex(self):
self.x = 7
h = Hello()
print(h.x)
h.ex()
print(h.x)
Both programs return:
0
7
Here are my questions:
Is the Python Code correct?
The programming style of Python appears to me to be more compact, compared to Java. So I am wondering, WHY does Python require the passing of a "self" -- Parameter.
At this point Python seems to be more "complex" than Java. Or is there a way to remove the "self" -- Parameter?

First, your python code is correct.
It's just a matter about how the languages is designed. Java uses a kind of automatic inference of a reference to the object. It can lead sometimes to strange behaviours for non-java experts:
private int a;
public int add(int a, int b){
return a+b; // what a will it use?
}
So, it's why in java there's the keyword this that can be used (but you're not forced) in order to solve that ambiguity.
The python team decided to force to use the word self (or any other word but I will explain later) to avoid that kind of problem. You cannot get rid of it. Though, java is still a more verbose language than python and the keyword self doesn't affect a lot that assumption.
However you're not obliged to use the "self" word as a reference to the current object. You can use any other word that would be the first parameter of your method (but it's a very bad practice).
Here, you can see two references that explain deeply why "self is here to stay":
http://www.programiz.com/article/python-self-why
http://neopythonic.blogspot.be/2008/10/why-explicit-self-has-to-stay.html

So in java the structure is generally
Class
private data (aka the "struct")
public data
constructors (__init__ in python)
functions etc
its very similar in python. same structure just for any functions working with the data you need to put self as an argument. where java it didn't have to take arguments.
Also it seems in python all data is public by default so you don't need to use getters and setters like in java.
personally I find a Python class more of a C-Struct with some added features, where java everything is thrown into a class.

For what's worth you can save a few line of codes when you have many fields, by using a library to remove the boilerplate. For example with pyfields:
from pyfields import field, make_init
class Hello:
x = field(default=0)
y = field()
__init__ = make_init()
h = Hello(y=10)
print((h.x, h.y))
yields
(0, 10)
You can even combine it with autoclass to get several features out of the box:
from autoclass import autoclass
from pyfields import field
#autoclass
class Hello:
x = field(default=0)
y = field()
h = Hello(y=1)
print(h)
assert h == {'x': 0, 'y': 1}
print(dict(h))
yields
Hello(x=0, y=1)
{'x': 0, 'y': 1}
See documentation for details. I'm the author by the way ;)

2.)Python is a high level language. where java is more mid-high im guessing. kind of new to java.
python goes by white space, where java requires more formatting.
3.) the self parameter can be removed. replace with whatever you want to call it.

Convention: when writing methods, should I return values, or change data directly?

I have been writing both Java and Python code for some time now. I have noticed, many times, that objects in both languages often have seemingly inconsistent ways to call their methods. Take these Python code snippets for example. (The syntax is not important, just note the way the methods work with the data)
class Foo(object):
def __init__(self, num = 0):
self.num = num
def __str__(self):
return str(self.num)
def addOne(self):
self.num += 1
if __name__ == "__main__":
foo = Foo()
print(foo) # Outputs 0
foo.addOne()
print(foo) # Outputs 1
Versus:
class Bar(object):
def __init__(self, num = 0):
self.num = num
def __str__(self):
return str(num)
def addOne(self):
return Bar(num + 1)
if __name__ == "__main__":
bar = Bar()
print(bar) # Outputs 0
bar.addOne()
print(bar) # Still Outputs 0
bar = bar.addOne()
print(bar) # Now Outputs 1
Both of these examples are very similar, but the Foo class, when you call Foo.addOne(), changes the num variable inside of the class. The Bar class, however, its addOne() method returns a new object with the num variable updated. Which situation is preferable at what times, what do people expect, and does this differ much in between languages?

Java has certain classes that are immutable. You (as a Java developer) can also create such classes. You cannot change the internal state of any object from an immutable class even if you want to (e.g. you cannot add 1 to an Integer object without creating a new Integer object, and you cannot append "a" to a String object without creating a new String object even if you want to).
Now, if a class is not immutable, you're free to take both approaches (change the internal state of the existing instance, or create a new instance). But whichever approach you take, you should document it so that your callers know what to expect. That's how it works in the Java world at least, as far as I'm aware.

Short answer: there's no such convention. As a language, Python combines both object-oriented and functional paradigms. For me personally, the choice which one to pick in each particular case is the most subtile skill for a Python developer.
You should answer lots of questions, e.g. how your object should be used? would it be shared among threads? is performance an issue? what are the conventions of application architecture? Perhaps the answers would later change so be ready for refactoring.
Python is much less restrictive that Java and cannot give any guarantees concerning the state of an object. It can neither make assumptions to perform low-level performance optimisations as Java do. So the definition 'mutable'/'immutable' is a mere convention for Python classes. It's more how we understand the object than a technical feature of the language.
In general case (or in doubt) I'd suggest to follow the POLA principle and stick to common patterns. For example, if your object behaves like a string, return new instance; if like a dictionary, perform in-place modifications. Extreme cases are usually wrong, good Python design uses the best of two worlds.

Java: Unit-Testing cascaded external interfaces

Consider a class that uses an external jar. The class processes objects of type D, which are obtained via objects A, B, and C, all of which external objects from the jar.
class DProcessor() {
public void process(PoolOfA pool) {
A a = pool.borrowObject()
...
B b = a.getB()
C c = b.getC()
for (D d : c.getAllDs()) {
// Do something meaningful with d
}
}
}
How do I Unit test process(PoolOfA pool)?
My best shot so far is writing mocks for all external classes:
PoolOfA pool = mock(PoolOfA.class);
A a = mock(A.class);
B b = mock(B.class);
C c = mock(C.class);
D d1 = mock(D.class);
D d2 = mock(D.class);
D d3 = mock(D.class);
D d4 = mock(D.class);
List listOfDs = new ArrayList<D>();
listOfDs.add(d1);
listOfDs.add(d2);
listOfDs.add(d3);
listOfDs.add(d4);
// Set specific behaviour for each d
when(pool.borrowObject()).thenReturn(a);
when(b.getC()).thenReturn(a);
when(c.getAllDs()).thenReturn(d);
when(b.getC()).thenReturn(c);
when(c.getAllDs()).thenReturn(listOfDs);
This seems cumbersome and inelegant. Is there a better way?

Better way is to rewrite the method, of course. But if you cannot do it for some reason, mockito offers great feature called 'deep stubs'. Check out the docs.

What process really does, is process some Ds in the loop. I would first make it clear by changing the signature:
public void process(Collection<D> allDs)
Now you can test that more easily by mocking D only.
That method can either be public if it can replace the existing one or package private for example if you don't want to expose it. In that latter case, you might still want to test that the other process method (the one that takes a poolOfA) properly extract the Ds. But that means that process(PoolOfA) needs to know a lot about the poolOfA which does not seem right.
This is one of the ideas promoted by this "Guide to writing testable code" which I think contains interesting concepts. What you mention would probably fall into the "Digging into Collaborators" section.

I would suggest a small redesign of the process method: It is currently responsible for doing two things: Extracting an Iterable of D's from the internals of the input and processing them.
So actually, you method, although declaring that it is expecting an input of type PoolOfA, is absolutely not interested in this object. It wants what's inside. I wold declare the method as taking an Iterable and pass the responsibility to the caller to give it the correct input. This will clarify the intention of the method and make it easier to test.
You may say: "this is not a real solution, this is just moving the problem to another location!
now I need to test the calling method!"
Well, yes and no. First, remember that you do not have to UT everything, just for the sake of coverage. You should focus your UT efforts on algorithmic pieces of code, it is OK to skip trivial object interactions.
If you insist, you can use more powerful mocking libraries like PowerMock in order to mock only past of your class, but this is a discussion for a different Question.

Regarding two lines of java code

I am trying to learn a java-based program, but I am pretty new to java. I am quite confusing on the following two lines of java code. I think my confusion comes from the concepts including “class” and “cast”, but just do not know how to analyze.
For this one
XValidatingObjectCorpus<Classified<CharSequence>> corpus
= new XValidatingObjectCorpus<Classified<CharSequence>>(numFolds);
What is <Classified<CharSequence>> used for in terms of Java programming? How to understand its relationships with XValidatingObjectCorpusand corpus
For the second one
LogisticRegressionClassifier<CharSequence> classifier
= LogisticRegressionClassifier.<CharSequence>train(para1, para2, para3)
How to understand the right side of LogisticRegressionClassifier.<CharSequence>train? What is the difference between LogisticRegressionClassifier.<CharSequence>train and LogisticRegressionClassifier<CharSequence> classifier
?

These are called generics. They tell Java to make an instance of the outer class - either XValidatingObjectCorpus or LogisticRegressionClassifier - using the type of the inner object.
Normally, these are used for lists and arrays, such as ArrayList or HashMap.
What is the relationship between XValidatingObjectCorpus and corpus?
corpus is just a name given to the new XValidatingObjectCorpus object that you make with that statement (hence the = new... part).
What does LogisticRegressionClassifier.<CharSequence>train mean?
I have no idea, really. I suggest looking at the API for that (I think this is the right class).
What is the difference between LogisticRegressionClassifier.<CharSequence>train and LogisticRegressionClassifier<CharSequence> classifier?
You can't really compare these two. The one on the left of the = is the object identifier, and the one on the right is the allocator (probably the wrong word, but it is what it does, kind of).
Together, the two define an instance of LogisticRegressionClassifier, saying to create that type of object, call it classifier, and then give it the value returned by the train() method. Again, look at the API to understand it more.
By the way, these look like wretched examples to be learning Java with. Start with something simple, or at least an easier part of the code. It looks like someone had way too much fun with long names (the API has even longer names). Seriously though, I only just got to fully understanding this, and Java was my main language for quite a while (It gets really confusing when you try and do simple things). Anyways, good luck!

public class Sample<T> { // T implies Generic implementation, T can be substituted with any object.
static <T> Sample<T> train(int par1, int par2, int par3){
return new Sample<T>(); // you are calling the Generic method to return Sample object which works with a particular type of generic object, may it be an Integer or a CharSequence. --> see the main method.
}
public static void main(String ... a)
{
int par1 = 0, par2 = 0, par3 = 1;
// Here you are returning Sample object which works with a sequence of characters.
Sample<CharSequence> sample = Sample.<CharSequence>train(par1, par2, par3);
// Here you are returning Sample object which works with Integer values.
Sample<CharSequence> sample1 = Sample.<Integer>train(par1, par2, par3);
}
}

<Classified<CharSequence>> is a generic parameter.
LogisticRegressionClassifier<CharSequence> is a generic type.
LogisticRegresstionClassifier.<CharSequence>train is a generic method.
Java Generics Tutorial

calling java method one after each other with "dots" in between

I see the following code syntax. Calling
ConfigurationBuilder cb = new ConfigurationBuilder();
cb.setDebugEnabled(true)
.setOAuthConsumerKey("x11")
.setOAuthConsumerSecret("x33")
.setOAuthAccessToken("x55")
.setOAuthAccessTokenSecret("x66");
All the methods after each other without using the object instance.
How does this work in programming my own class when i want to use this kind of calling methods?

make each of those methods return the same object which they are called on:
class MyClass{
public MyClass f(){
//do stuff
return this;
}
}
It's a pretty common pattern. Have you ever seen this in C++?
int number=654;
cout<<"this string and a number: "<<number<<endl;
each call of the operator << returns the same ostream that is passed as its argument, so in this case cout, and since this operation is done left to right, it correctly prints the number after the string.

That style of writing code is called 'fluent' and it is equivalent to this:
cb.setDebugEnabled(true);
cb.setOAuthConsumerKey("x11");
cb.setOAuthConsumerSecret("x33");
cb.setOAuthAccessToken("x55");
cb.setOAuthAccessTokenSecret("x66");
Each method returns 'this' in order to accommodate this style.
If you use this style, be prepared to encounter some inconvenience while debugging your code, because if you want to single-step into only one of those methods instead of each and every single one of them, the debugger might not necessarily give you the option to do that.

This is simmilar to a Builder design pattern.
Here you can find a excellent example of it inspired by Josh Bloch's code from Effective Java 2nd ed.