Showing posts with label python. Show all posts
Showing posts with label python. Show all posts

Wednesday, September 16, 2009

Preaching Python : The obstacles

I am a big fan of Python. I am a Windows Developer. I’ve been doing C/C++ as long as i can remember before jumping to C# to leverage on the .NET.

I abandoned Java when it was 2 years old, it just never got me attracted. Maybe its because my field centralizes on system level and security and not enterprise business applications. 

Python has a distinct place in development today. But try convincing the following crowd :-

1. A Windows C#/ASP.NET developer, been using VB since 1997.

2. Java Developer with over 7 years of exp

3. C++ /C hardcore

4. PHP developer

Here are the list of the most common obstacles :

1. Python is SLOW

2. Python has no strong Enterprise Framework

3. Python has weak data typing, its hard to create APIs for users to extend.

4. C# can do everything that Python can and it works better in Windows and..faster.

5. Python GUI development in Windows sucks.

6. see no.1

Python is slow. Compared to  C. Which language is faster than C ? Assembly maybe but definitely not Java or C#.  Does the program speed really matter so much when practically in most applications the speed differences might not even exist to be practical.

Lets say you are developing a Network application that accepts data from the Internet and do something with it. The internet bandwidth speed from your ISP to you is nothing compared to your LAN speed. Lately The CPU processing power has grown from exponential to straight upward beating Moore’s Law.  In this case python would do perfectly well, the bottleneck is not the application speed but rather the internet speed.

One of the exceptions would be if you are doing scientific research and mathematical data of which nanoseconds per iteration differences might matter to you.

Python is slow? Use C then for the part that requires special computational algorithm . Recently a friend of mine showed me a game called Civilization, its the latest version and it uses Python. It runs fast and flawlessly on my Vista. I believe they used python just for the main framework of the game coding while the graphic rendering is back to C/C++ . Now that is smart.

Python is slow? Blink. Did u see the difference?

Thursday, August 7, 2008

Python : Working Directory Woes

Python has unittest that allows you to have a framework for testing your modules.
There is also nosetests. If you are using Wing IDE, there is a built in Test panel.
All is beautiful.

The problem is, if your project uses calls to "locate directory of where your script ran" you're in for a ride. Unlike windows api where u have a definite api to get this, the various ways in python to get the value resides in os.sys.path[0], sys.argv[0] and os.getcwd().

ALL the values you have seen will not get you the values you want, in unix when its run by using python or using the crond or when you run it from another script located elsewhere or in windows when you run it with "unittest, nosetests and even the Wing's Test panel" these values are going to give you a different result.

And then there is the py2exe ....which will give you yet another surprise as the path return is "\dist\library.zip"

Solution :

Temporarily put some guards for tests enviroment and use the following :-

def GetCurrentWorkingDir () :

if "Wing" in sys.argv[0] : return os.sys.path[0] + os.sep
if "nosetests" in sys.argv[0] : return os.sys.path[0] + os.sep

return os.path.abspath(os.path.join(os.path.dirname(sys.argv[0]))) + os.sep