Python has a sizeable standard library. It is this standard library the provides a lot of the power of Python as a language.

Much of this standard library is implemented in Python, and could be converted into a Jar file using VOC. VOC's build system should be modified to perform this conversion.

Other parts of the standard library are implemented in C, and will require re-implementation in Java.

Even if there is a pure-python implementation, it may be desirable to re-implement a standard module in Java for efficiency purposes.

This may be dependent on completion of #36 and #38, as you won't be able to use the standard library unless the builtin data types are available.

I struggled through a few issues to get a dev environment up and running on Windows (e.g., pyenv is not supported on Windows and has little/no interest in being so). I'd like to add some detail in an appropriate place on ways for Windows devs to set things up, just not totally sure where that should go so as not to clutter things unnecessarily for the main path.

I followed instruction on how to set up a dev environment. When I run the tests I get at the end of the procedure a number of errors due to missing files. I am running on an Ubuntu 16.4 VM, Python 3.4.5, javac 1.8.0_91 (openJDK) , ant 1.9.6 . Below a sample of the errors I get:

ERROR: setUpClass (tests.structures.test_java.JavaTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/luca/voc-dev/voc/tests/utils.py", line 276, in setUpClass
    setUpSuite()
  File "/home/luca/voc-dev/voc/tests/utils.py", line 60, in setUpSuite
    out, err = proc.communicate(timeout=15)
  File "/usr/lib/python3.4/subprocess.py", line 959, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "/usr/lib/python3.4/subprocess.py", line 1621, in _communicate
    self._check_timeout(endtime, orig_timeout)
  File "/usr/lib/python3.4/subprocess.py", line 985, in _check_timeout
    raise TimeoutExpired(self.args, orig_timeout)
subprocess.TimeoutExpired: Command 'ant java' timed out after 15 seconds

----------------------------------------------------------------------
Ran 31 tests in 4771.214s

FAILED (errors=173)
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/home/luca/voc-dev/env/lib/python3.4/shutil.py", line 457, in rmtree
    orig_st = os.lstat(path)
FileNotFoundError: [Errno 2] No such file or directory: '/home/luca/voc-dev/voc/tests/tmpbf9imex0'

Here are some test cases that don't work as expected (tested creating a file testraise.py, putting these snippets on it then compiling w/ VOC and running):

raise ValueError("test")

results in:

Exception in thread "main" java.lang.NoSuchMethodError: org.python.exceptions.ValueError.<init>(Lorg/python/Object;)V
	at python.testraise.__init__.module$import(testraise.py:1)
	at python.testraise.__init__.main(testraise.py)

However, if you do raise ValueError() (no args), the exception is raised normally.

The inverse happens for KeyError: if you don't give it an argument, it fails with the same error as above, but it works if you give it an argument.

A few other exceptions I tested (TypeError, AttributeError and KeyboardInterrupt) also have the same failure pattern as ValueError, there are probably more of this.

Another thing to note (possibly related) is that this also fails: (EDIT: removed separate error, which was duplicate of #350)

NotImplementedError: No handler for Lambda ,seems lamda functions not working for me, any workaround??

If you define a method in Python, VOC will potentially generate three Java-side methods to represent that method:

• A binding method, representing the Java interface to the method. This will be typed using the specific types annotated in the Python code
• A super method, with the same prototype as the binding, but explicitly invoking the super.method()
• The Implementation, representing the actual Python logic. All arguments to this method will be org.python.Object, as will the return type. All implementation methods are static; the first argument is the org.python.Object representing the instance. This largely mirrors Python's own behavior.

When you invoke a Python method from within Python, the implementation is called directly. However, if you invoke from Java, the binding is invoked; this transforms the typed arguments into Python-compatible objects, and invokes the implementation.

At present, the implementation and binding have the same method name, but different prototypes (pure Java types for the binding; static org.python.Object types for the implementation). However, if a method foobar() needs a super, the super method will be called foobar$super(). This is not a legal name in Java syntax, but it is a legal and accessible symbol name. As a result, we can create a super method without any risk of namespace clashes.

It would be desirable for the implementation method to also have a modifier (foobar$py()) to make it clear that the method should only be invoked from within a Python context.

with and async/await is missing

raise NotImplementedError('No handler for With')

I've noticed there are some tests in tests/datatypes/test_str that are passing because they're raising the same error, but aren't doing what they're supposing to be doing.

There are also some tests that can be simplified because they have the same setup code (use the same basic string, but several calls to assertCodeExecution).

I'm adding this issue as a reminder for myself to review and cleanup them (can't do it right in this moment).

I think it would be nice to add an optional parameter expected_output to TranspileTestCase.assertCodeExecution to be checked w/ Python and Java output, to ensure that it's what we expect.

I was testing out the behavior of the method signatures before sending #288, and found some unexpected behaviors.

There is probably a better way of testing this, but I did my tests adding these two test methods to the List object:

    @org.python.Method(
        __doc__ = "",
        default_args = {"arg1", "arg2"}
    )
    public org.python.Object some_method(org.python.Object arg1, org.python.Object arg2) {
        System.out.printf("some_method: arg1: %s\n", arg1);
        System.out.printf("some_method: arg2: %s\n", arg2);
        return org.python.types.NoneType.NONE;
    }

    @org.python.Method(
        __doc__ = "",
        args = {"arg1"},
        varargs = "others"
    )
    public org.python.Object method_varargs(org.python.Object arg1, org.python.types.Tuple others) {
        System.out.printf("method_varargs: arg1: %s\n", arg1);
        System.out.printf("method_varargs: others: %s\n", others);
        return org.python.types.NoneType.NONE;
    }

And then I wrote some different combinations of passing arguments, and these two cases in which I pass unexpected arguments result in unexpected behavior:

li = [1, 2, 3]

print("\nli.some_method(1, 'two', 3)")
li.some_method(1, 'two', 3)

print("\nli.method_varargs()")
li.method_varargs()

This is the output for the above program:

li.some_method(1, 'two', 3)
some_method: arg1: 1
some_method: arg2: two

li.method_varargs()
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: -1
    at java.util.ArrayList.elementData(ArrayList.java:418)
    at java.util.ArrayList.get(ArrayList.java:431)
    at org.python.types.Function.adjustArguments(Function.java:251)
    at org.python.types.Function.invoke(Function.java:320)
    at org.python.types.Method.invoke(Method.java:41)
    at python.argstest.__init__.module$import(argstest.py:7)
    at python.argstest.__init__.main(argstest.py)

In both cases I expected to get a TypeError complaining about passing wrong number of arguments, but in the first case the extra argument was silently ignored and in the second case the missing argument causes a Java runtime level exception.

VOC currently assumes all arguments are instances of objects implementing org.python.Object. This makes the compiler easy to write, but it requires conversions from and to object form of primitive data types.

In some cases, however, type information is available for parameters. This type information could be used to optimize code paths. For example, if we know an argument is an integer, and is only ever used as an integer, there's no need to convert it to org.python.types.Integer and back again just to perform a simple mathematical operation; the integer Java opcodes could be used directly on the argument.

This should result in a significant performance improvement for VOC-compiled code.

Please update the python version requirement to 3.5+ instead of 3.4+.
It took me a lot of time to figure this out, since I had Python 3.5.2 installed on my system and still, while installing VOC, I got error message saying:
VOC requires Python 3.4+
This was resolved once I changed this in the setup.py file.

Seems like with pattern is missing/not supported yet, which is very popular and exists in Python since 2.5.
Started this as seperate issue as said by @eliasdorneles in #245

This is an early heads up that CPython will be switching to a 16-bit wordcode format as of 3.6a2: http://bugs.python.org/issue26647

The change itself is in https://hg.python.org/cpython/rev/3a57eafd8401

In theory this should be a transparent change for any project that interacts with compiled code solely through the dis module, but since VoC transpiles CPython bytecode I figured you may want to take a closer look at the implications.

The builtin types of Python have a number of methods associated with them - for example, dict objects have update(), items(), keys(), pop() and so on. These methods need to be implemented in Java. In many cases, there will be a simple mapping to an analogous function in the underlying Java type; however, sometimes you'll need to write an implementation using the available Java primitives.

Tests are are also required; they should go in the module corresponding to the data type in the tests/datatypes directory.

Tests are based on comparing the output of some sample Python code when run through CPython to the output when run through VOC. When the two outputs are identical - and I mean byte-identical, down to the text and punctuation of the error message if appropriate - the test passes.

If you want an example to follow, look at the implementation of clear() on dict:

• The @org.python.Method annotation is used to expose the clear() method as a symbol that should be available at runtime.
• All arguments are exposed as org.python.Object, and then cast to the right data type as required.
• Finally, the method returns a Python None.

It is now possible to raise only exceptions from package org.python.exceptions. So for raise custom python exception there are 2 option:

1. Rebuild java-python-support.jar with your exception.
2. Write on java exception proxy-class.

In the getting started section of the docs should be mentioned that voc won't build on Python3.5+.
The default version apt-get provides on Ubuntu 16.04 is 3.5+, it should be mentioned that a separate
Python 3.4+ is required.
Accordingly in the page "Contributing to VOC"
https://voc.readthedocs.io/en/latest/internals/contributing.html
there shouldn't be a reference to libpython3.5-testsuite.

When trying to install Voc as suggested in the documentation:

pip install voc

an error is raised:

Collecting voc
  Could not find a version that satisfies the requirement voc (from versions: )
  No matching distribution found for voc

The version of pip is not really the problem (it doesn't work with pip 6.1.1 nor with pip 7.1.2).
Trying to install it with the verbose option leads to the probable root cause:

(voc)p@pc:~/voc$ pip install -v voc
Collecting voc
  Getting page https://pypi.python.org/simple/voc/
  Starting new HTTPS connection (1): pypi.python.org
  "GET /simple/voc/ HTTP/1.1" 200 111
  1 location(s) to search for versions of voc:
  * https://pypi.python.org/simple/voc/
  Getting page https://pypi.python.org/simple/voc/
  Analyzing links from page https://pypi.python.org/simple/voc/
  Could not find a version that satisfies the requirement voc (from versions: )
Cleaning up...
No matching distribution found for voc
Exception information:
Traceback (most recent call last):
  File "/home/p/.virtualenvs/voc/local/lib/python2.7/site-packages/pip/basecommand.py", line 211, in main
    status = self.run(options, args)
  File "/home/p/.virtualenvs/voc/local/lib/python2.7/site-packages/pip/commands/install.py", line 294, in run
    requirement_set.prepare_files(finder)
  File "/home/p/.virtualenvs/voc/local/lib/python2.7/site-packages/pip/req/req_set.py", line 334, in prepare_files
    functools.partial(self._prepare_file, finder))
  File "/home/p/.virtualenvs/voc/local/lib/python2.7/site-packages/pip/req/req_set.py", line 321, in _walk_req_to_install
    more_reqs = handler(req_to_install)
  File "/home/p/.virtualenvs/voc/local/lib/python2.7/site-packages/pip/req/req_set.py", line 461, in _prepare_file
    req_to_install.populate_link(finder, self.upgrade)
  File "/home/p/.virtualenvs/voc/local/lib/python2.7/site-packages/pip/req/req_install.py", line 250, in populate_link
    self.link = finder.find_requirement(self, upgrade)
  File "/home/p/.virtualenvs/voc/local/lib/python2.7/site-packages/pip/index.py", line 571, in find_requirement
    'No matching distribution found for %s' % req
DistributionNotFound: No matching distribution found for voc

The root cause is probably the page https://pypi.python.org/simple/voc/, being it completely blank.

Hi,
I'm in the process of installing the dev environment for VOC and when I tried to install 3.4 and got the following error

Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libpython3.4-testsuite
E: Couldn't find any package by glob 'libpython3.4-testsuite'
E: Couldn't find any package by regex 'libpython3.4-testsuite'

I had to run the following command to fix it:

sudo apt-get install libpython3.5-testsuite

For most of the methods, args have not been defined, which leads to the following problem.

5*6 is executed succesfully
However, 5.mul(6) throws an error. For every method, the args need to be defined.

The stack trace for:

# test.py
a = 4
print(a.__mul__(5))

Comes out to be:

Exception in thread "main" java.lang.IllegalArgumentException: wrong number of arguments
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.python.types.Function.invoke(Function.java:275)
    at org.python.types.Method.invoke(Method.java:44)
    at python.test.__init__.module$import(test.py:2)
    at python.test.__init__.main(test.py)

The operators are checked, however the underlying methods throw an error.
This arose in a conversion with @cflee
He suggested to bridge this gap by modifying the tests/utils.py to test the math operators.

Java has a specific set of allowed operator and operations. Python has a set of operators and operations as well. However, the two don't match exactly. For example, Java will allow any object to be added to a java.lang.String; Python does not. On the other hand, Python allows multiplication of str by int (producing a duplicated string); Java does not.

In order to replicate Python behavior in Java, Python's logic for all the basic operations needs to be implemented in the VOC Java support library.

The test suite contains around 2800 tests in the that are currently marked as "expected failures". These reflect an attempt to do "every operation between every base data type". The task: pick a data type, and write the implementation of one of the dunder operation (e.g., __add__ or __xor__) or comparison (__lt__ or __eq__) methods.

The tests will pass (and become unexpected successes) when the output of Python code doing that operation is the same when run through CPython and VOC - and I mean byte-identical, down to the text and punctuation of the error message if appropriate.

If you want to see an example of what is involved, check out the implementation of add for integers. If you have an int, Python will allows you to add an int or a float to it; all other types raise a TypeError. The list of operations on int that still need to be implemented can be found here; if you add a new operation, delete the line that corresponds to that test, and the test will report as a pass, rather than an expected fail.

Current org.python.types.Tuple uses a List<Object> as its internal implementation; takes a List as its argument constructor and stores a reference to it.

This is sub-optimal, because a Python tuple is immutable. An Array would avoid dragging in all the resize mechanisms.

But further, it is incorrect, because a Python tuple should not change when the value used to construct it changes.

Java 7 added the requirement for a Stack Map to track usage of the stack during operation. The Java 7 JVM validates this Stack Map at startup.

voc doesn't currently generate Stack Maps, and as a result, it is necessary to use -XX:-UseSplitVerifier argument to the JVM.

I believe there is sufficient information in the data model to generate Stack Maps - it's just matter of doing the work.

1. JVM doesn't start:
   File "voc\tests\utils.py", line 500, in runAsJava
   self.jvm.stdin.flush()
   OSError: [Errno 22] Invalid argument
2. File write failed:
   File "env\lib\encodings\cp1251.py", line 19, in encode
   UnicodeEncodeError: 'charmap' codec can't encode character '\xff' in position 678: character maps to

python3.5 async/await feature will be a good feature to see split the issue #245 seperate.
clojurescript like csp feature is another way to solve instead of callbacks

The current test runner validates Java output by starting a fresh VM for every test. However, JVM warmup is time-expensive operation.

Ideally, we'd be able to use a single JVM instance, and run each test in that instance, rather than restarting the JVM each time.

If necessary, this could be done on a per-TestCase or per test Module level.

org.Python is a Java implementation of all the Python builtins - methods like print(), input(), list(), abs(), min() and so on.

An implementation of these builtins is required.

After some experimenting, I ran into a case where the transpiler gives an error.

for k in []:
    pass
else:
    print("nobreak")

This is as far as I could get to a minimal (non-)working example. Replacing the print with pass makes it get optimised out by Python already, so the transpiler works.

Opening a web link to read the getting started docs is kind of a pain (and doesn't work if I've already gone offline).

Currently, the improved Java test runner (refs: issue #13, PR #98) uses a single JVM that runs the python.testdaemon.TestDaemon class, to execute the various transpiled classes in tests/utils.py's runAsJava() and assertJavaExecution(). Class names are fed in via stdin, and the resulting output is retrieved from stdout. For each test, the main Thread's ContextClassLoader is set to a new JoinClassLoader instance that routes org.python.* classes to a URLClassLoader for python-java.jar, and all other classes to a URLClassLoader for the temp/ and java/ directories.

However, there are some issues with this implementation:

• sys.argv contains the parameters used to invoke the JVM, i.e. the python.testdaemon.TestDaemon class, and not the args that are passed together with the class name on stdin. The current workaround is to fallback to the 'old' Java test runner that starts up a new JVM instance for each test that has non-empty args parameter. This will be increasingly non-ideal if more tests supply args.
• The runtime parts of voc now have to use java.lang.Thread.currentThread().getContextClassLoader().loadClass() instead of the more common Class.forName(), in order to use the appropriate ClassLoader to load the correct Class. Specifically, it needs to use the current test's instance of JoinClassLoader, instead of the ClassLoader that was used to create the calling class.
  • This is seen in org.python.ImportLib, org.python.types.Type, org.python.java.Type, and org.python.java.Module.
  • There are some subtleties involved in dynamic loading beyond merely classloading. For example, it was observed that a org.python.java.Type object cannot be cast to its supertype org.python.types.Type when the objects/classes are loaded from different ClassLoaders! This is because class identity in the JVM is defined by both the fully qualified class name as well as the class loader.

The easiest way is to entirely switch off the caching that is being done on the classes from python-java.jar, but that makes the test runtime multiply by ~3.5 (250% increase). It would be best if there's some kind of middle ground where there is a small or no increase in runtime, while still being able to switch back to using Class.forName() in the main codebase.

Possible approaches I can think of currently include:

• Tweaking the current JoinClassLoader approach to adjust what classes are cached and which URLClassLoader is to load what classes
• Implementing a full ClassLoader to replace URLClassLoader, so that a single ClassLoader can be used in a way that sidesteps the classes-can-only-be-loaded-once behaviour without upsetting the JVM

For more details about the concerns, see this comment on #98 by @freakboy3742.

import from java.awt.event import ActionListener

class MyActionListener(implements=ActionListener):
    pass

vs

class MyActionListener(implements=java.awt.event.ActionListener):
    pass

This is apparently also an issue for type annotations on function arguments and return types.

Can type annotations be optionally used to improve performance if enforced at runtime, or the program is strictly analyzed at compile time?

Either for this or any of the other projects.

This code snippet:

print(dict(a=1, b=2))

After compiling and running with VOC, is printing empty dict:

{}

And this is raising KeyError:

d = dict(a=1, b=2)
d['a']

Given this Python code:

print('A')

if __name__ == '__main__':
    print('B')

print('C')

CPython prints ABC, while VOC prints ACB. This causes at least two tests to fail. [1]

This arises from how VOC is transforming the Python if __name__ == "__main__": statement. B is placed into the Java main() method, while A and C are placed into module$import().

At runtime, the JVM starts with the main() method, which first invokes module$import(), then proceeds to B. This is incorrect behaviour.

One possible fix is to move the children of if __name__ == "__main__": into something like module$main(), and change main() to invoke module$import() with a flag main=true. The latter then contains a conditional that invokes module$main() at the spot where is_mainline_def() is found.

[1] tests.structures.test_function.FunctionTests.test_mainline and tests.stdlib.test_sys.SysModuleTests.test_exit

In Your-first-VOC-contribution.md, a wrong reference is given for the implementation of the mul() function.

https://github.com/pybee/voc/blob/master/python/common/org/python/types/Str.java#L309

(This is on Windows 8.1; I imagine similar issues appear on other Windows systems)

I've had a try at running the tests under Windows, the main failure that I run into seems to be related to the default encoding under Windows (cp1252 rather than utf-8):

E AssertionError: 'utf-8' codec can't decode byte 0xff in position 10: invalid start byte

This seems to be an issue on both the Java and Python versions, see attached voc_output.txt, which is a dump of the main_code for both runAsPython() and runAsJava()

Another, possibly related issue is that Windows has a "charmap" encoding in it's terminals (cmd and powershell), which doesn't handle some unicode characters. I've also attached
unicode_test.py.txt which blows up with a similar error.

In the process of debugging, I've also found a couple of places where utf-8 encoding seems to have been missed - pull request here: #236

It says $ python -m voc tests/example.py org.pyee when I'm guessing it should be $ python -m voc tests/example.py org.pybee

The "fork the code" at the bottom links to https://github.com/freakboy3742/voc instead of https://github.com/pybee/voc

Hi,

I'm just trying to help. In a recent search for a friend I've found the following projects:

1. https://github.com/chrishumphreys/p2j - Code converter. Old but worked at some point.
2. https://www.py4j.org/index.html - Allows python code to access jvm objects
3. https://github.com/LeeKamentsky/python-javabridge/ - Same as 2.
4. https://github.com/originell/jpype - Allows python to call java code. You might want to use it.

Hope some of them will help you

'nuff said. :-)

Anything would be better than just the README.

It looks like the common idiom self.__class__ doesn't work with VOC classes.

Steps to reproduce:

Create a file testclass.py with the following code:

class Hello:
    def hello(self):
        print('hello, from class %s' % self.__class__.__name__)

Hello().hello()

Expected behavior:

$ python testclass.py 
hello, from class Hello

However, this is what you get using VOC:

$ voc -v testclass.py
Compiling testclass.py ...
Adding default main method...
Writing ./python/testclass/__init__.class ...
Writing ./python/testclass/Hello.class ...
$ java -cp ../voc/dist/python-java-support.jar:. python.testclass.__init__
Exception in thread "main" AttributeError: 'Hello' object has no attribute '__class__'
	at org.python.types.Object.__getattribute__(Object.java:288)
	at python.testclass.Hello.hello(testclass.py:3)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.python.types.Function.invoke(Function.java:391)
	at org.python.types.Method.invoke(Method.java:48)
	at python.testclass.__init__.module$import(testclass.py:5)
	at python.testclass.__init__.main(testclass.py)

Environment details:

$ javac -version
javac 1.8.0_121
$ python --version
Python 3.4.4

pybee/Ouroboros provides a pure Python implementation of the Python standard library. That Python code can be compiled directly into Java classifies and converted into a standard library that can ship as part of the VOC support libraries, supplemented by native implementations as required (see #74).

Via Kesha Shah:
The CI server runs under Python 3.4.2, and is (usually) in a fully passing state.

However, if you run the test suite under Python 3.4.4, you will get 3 test failures:

======================================================================
FAIL: test_list (tests.builtins.test_int.BuiltinIntFunctionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 641, in func
    self.assertBuiltinFunction(x=example, f=function, operation=operation, format=self.format)
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 661, in assertBuiltinFunction
    """ % kwargs, "Error running %(operation)s with f=%(f)s, x=%(x)s" % kwargs)
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 373, in assertCodeExecution
    self.assertEqual(java_out, py_out, context)
AssertionError: "### [52 chars]tring or a number, not 'list'\n    test.py:3\n" != "### [52 chars]tring, a bytes-like object or a number, not 'l[17 chars]:3\n"
  ### EXCEPTION ###
- TypeError: int() argument must be a string or a number, not 'list'
+ TypeError: int() argument must be a string, a bytes-like object or a number, not 'list'
?                                           +++++++++++++++++++++
      test.py:3
 : Global context: Error running f(x) with f=int, x=[]

======================================================================
FAIL: test_none (tests.builtins.test_int.BuiltinIntFunctionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 641, in func
    self.assertBuiltinFunction(x=example, f=function, operation=operation, format=self.format)
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 661, in assertBuiltinFunction
    """ % kwargs, "Error running %(operation)s with f=%(f)s, x=%(x)s" % kwargs)
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 373, in assertCodeExecution
    self.assertEqual(java_out, py_out, context)
AssertionError: "### [52 chars]tring or a number, not 'NoneType'\n    test.py:3\n" != "### [52 chars]tring, a bytes-like object or a number, not 'N[21 chars]:3\n"
  ### EXCEPTION ###
- TypeError: int() argument must be a string or a number, not 'NoneType'
+ TypeError: int() argument must be a string, a bytes-like object or a number, not 'NoneType'
?                                           +++++++++++++++++++++
      test.py:3
 : Global context: Error running f(x) with f=int, x=None

======================================================================
FAIL: test_tuple (tests.builtins.test_int.BuiltinIntFunctionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 641, in func
    self.assertBuiltinFunction(x=example, f=function, operation=operation, format=self.format)
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 661, in assertBuiltinFunction
    """ % kwargs, "Error running %(operation)s with f=%(f)s, x=%(x)s" % kwargs)
  File "/Users/keshashah/VOC/voc-dev/voc/tests/utils.py", line 373, in assertCodeExecution
    self.assertEqual(java_out, py_out, context)
AssertionError: "### [52 chars]tring or a number, not 'tuple'\n    test.py:3\n" != "### [52 chars]tring, a bytes-like object or a number, not 't[18 chars]:3\n"
  ### EXCEPTION ###
- TypeError: int() argument must be a string or a number, not 'tuple'
+ TypeError: int() argument must be a string, a bytes-like object or a number, not 'tuple'
?                                           +++++++++++++++++++++
      test.py:3
 : Global context: Error running f(x) with f=int, x=(1, 2.3456, 'another')

----------------------------------------------------------------------

It appears that Python 3.4.4 changed the error message raised by int() when invalid input is provided. Under 3.4.2, you get:

>>> int(list())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string or a number, not ‘list'

However under Python 3.4.4, you get:

>>> int(list())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int() argument must be a string, bytes-like object or a number, not ‘list’

VOC should standardise on the 3.4.4 message format (since that's the format that will exist into the future); the cleanse_python() method in tests/utils.py should normalize the error string from 3.4.2 format to 3.4.4 format if it is observed in Python test output.

I have a problem with exception raises.

1.Cant raise exception by class name.

test.py
---------------------
raise ValueError

  File "/home/user/Projects/voc/voc/python/ast.py", line 489, in visit_Raise
    exception = 'org/python/exceptions/%s' % node.exc.func.id
AttributeError: 'Name' object has no attribute 'func'

2.Cant raise instance of exception without arguments

test2.py
---------------------
raise ValueError()

   File "/home/inekipelov/PosterProjects/voc/voc/java/constants.py", line 391, in __init__
    self.descriptor = method_descriptor(descriptor)
  File "/home/inekipelov/PosterProjects/voc/voc/java/signatures.py", line 179, in method_descriptor
    return MethodDescriptor(parameters=matches[:-1], return_type=matches[-1])
IndexError: list index out of range

I keep getting this error: AttributeError: module 'voc.python.opcodes' has no attribute 'CALL_FUNCTION_KW'.

If we look at the Getting Started document, towards the end we have what looks like a broken link: :doc:start the first tutorial </tutorials/tutorial-0>. I tried to modify it to GitHub relative link format as given here but couldn't get it right. How are these to be fixed?

A linter needs to be added to travis, one that if possible, reports non-compliance the same way that a test failure reports - "tests passed", but "Python lint failed on file:<>"