Cyther: The Cross Platform Cython/Python Compiler

The newer version of this question is located here: Cyther: The Cross Platform Cython/Python Compiler (Take 2)

I am currently writing a Python library (soon to be published)that automatically compiles a Cython/Python file to pure -O3 C, without the user having to do anything other than:

C:\Project_dir\> cyther example.pyx

C:\Project_dir\> cyther example.py

from cyther import main
main('example.pyx')

My 'auto-compiler' is named Cyther, and it organizes and polymorphesizes Cython and gcc together in an attempt to make a platform independent, stable, and easy to use compiler.

Cyther was specifically designed to combat the vcvarsall.bat not found error on windows, but still work on every other system with exactly the same performance.

I need to make sure that it is completely cross-platform.

I've tried my best, but alas, I may have slipped up here and there. I am also not very familiar with the oddities of other operating systems. I was thinking about using a Virtual Box to run a few other operating systems to test Cyther on, but I can only get so far by trial and error.

The issue: Cyther makes a few assumptions about your system that I'm not sure how to handle:

• Your environment path variable is named 'PATH'

• Cython, Python and gcc are all '.exe'

• libpythonXY.a exists in your libs directory

• mingw32 is up to date with the latest Python release (Windows)

• 'cyther' is callable from the command line

• Any gcc compiled C program will work on Windows

```
__author__ = 'Nicholas C. Pandolfi'

license = '''
Copyright (c) 2016 Nicholas C Pandolfi ALL RIGHTS RESERVED (MIT)

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the

I will give a quick overview of some aspects that I found at a first glance. Unfortunately, I could not spare the time to do an in-depth analysis of the cross-plattform capabilites and/or thorough testing of your program. As I find your idea very interesting, I maybe check back later with more feedback.

Edit: Updated requirements for proper import and added some thoughts on the given assumptions.

Magic values

On the first sight, I was able to spot some magic values (like -42), which maybe should be replaced with a CONSTANT with a nice name (GCC_ERROR?).

Module level constants

The values of assumptions and the helper_* are constants in this module. It is common practice in Python to write such module level constants in ALL_UPPERCASE_LETTERS.

Missing docstrings

The next thing that caught my eye was a sincere lack of class/method/function docstrings. As the code (maybe) will be available to the public, assume someone will mess around with it. You may help others a lot if you tell them a little bit about each function and maybe the inputs it expects. The Python bible PEP257 is a good reference on this topic.

In addition some comments in the code may help to split longer functions into logical groups, which greatly simplifies rewiews and reworks of the code.

Redefinition of built-ins

With a little help from Spyder's synthax highlighting, I was able to find two redifintions of Python built-ins: license and file (talking from a Python 2.7 point of view, maybe that has changed). Refering to a SO answer, __license__ would be the way to go on this, whereas an alternative for file is left as an exercise to the dear reader.

Space around keyword arguments

Following the infamous PEP8, there should be no spaces around keyword arguments. As an example

parser = argparse.ArgumentParser(description = '...', usage = '...')

would end up as

parser = argparse.ArgumentParser(description='...', usage='...')

Typechecking

From my experience it is more common to check the type of an object with isintance instead of type. With that in mind type(args) == str becomes isinstance(args, str), for example.

Miscellaneous

One could move the whole parser initialization into the if __name__ == 'main': block. If you want to import your program, you will have to move command_line_args = parser.parse_args() to that block. Otherwise the parser will be started on import, which will cause an error because the script is called with no arguments.

The assumptions


1) Your environment path variable is named 'PATH'

All Linux and Windows systems I have worked on had an enviroment variable called PATH. It is an educated guess, but from my point of view that assumptions is valid.


2) Cython, Python and gcc are all '.exe'

This may be a bit problematic. Linux systems do not have .exe files usually. I can start the Python interpreter on Linux and Windows by typing python into the console if the executable is in PATH, but that may be caused by my setup. Maybe that can be exploited to check the pressence of Python and co.


3) libpythonXY.a exists in your libs directory

Linux seems to prefer .so as file extension for libpython (see this to the Ubuntu package repository for example)


4) mingw32 is up to date with the latest python release (windows)

I use Python library collections (Python(x,y) and/or Anaconda), of which at least one (to the best of my knowledge) comes bundled with its own version of MinGW. There is at least one more MinGW on my system. Following Murphy's Law, that may (and probably will) cause some hiccup, depending on which MinGW installation comes first in PATH.


5) 'cyther' is callable from the command line

You will have to take care the cyther is executable then. SO and the internet will give you a lot of advice how this can reached.


6) Any gcc compiled c program will work on windows

My experience says: "Not gonna happen!". Sorry. But I wish you the best of luck thay "any" will be "almost any".

StackExchange Code Review Q#123154, answer score: 4