Group items tagged

You can use Microsoft Script Control. If you have the win32 extensions of python, you can use python in place of vb in this control -open the VBA script editor - In menus/Tools/References add Microsoft Script Control -Make a new module and declare a new MsScriptControl.ScriptControl Global sc as new MsScriptControl.ScriptControl -Initialize the language attibute with python - Note that you and users of your document must have python and its win32 extensions installed. Activestate python distribustion include it. You can put sc.language="python" in the routine Workbook_Open() Now you can import python modules using ExecuteStatement method of the control in vba and have results from python functions with eval method. One interesting thing is that you can pass an object to the control with AddObject method and have python manipulate it. And so on..

Global sc As New MSScriptControl.ScriptControl Public Function os_getcwd() sc.Language = "python" sc.ExecuteStatement ("import os") os_getcwd = sc.Eval("os.getcwd()") End Function With this you can set your Excel formula to =os_getcwd() For me it returns "C:\Documents and Settings\Administrator\My Documents", which I needed to know at the time so I didn't have to screw around with the ever annoying pythonpath. You can put the first two lines of the function in the Workbook_Open hook, but I don't know where that is. I hope to use more Python in Excel soon. Hmm, actually, I suppose you can put those first two lines of the function after the Global declaration as well. I know just about zero VBScript and didn't get a chance to do anything else beyond proof of concept yet. I figured I would write something dynamic which allowed more transparent access to Python, maybe allowing formula like =py("os.getcwd()"), etc.

StatPy: Statistical Computing with Python Welcome to StatPy, a collection of resources to help you do statistical computing with Python, with a special emphasis on astrostatistics (statistics in astronomy). This web site is brand-spanking-new, and still very much under construction; please be patient with our "dust" and check back again frequently as building continues.

PyScripter is a free and open-source Python Integrated Development Environment (IDE) created with the ambition to become competitive in functionality with commercial Windows-based IDEs available for other languages. Being built in a compiled language is rather snappier than some of the other Python IDEs and provides an extensive blend of features that make it a productive Python development environment. 

In short: run your existing Python software much faster, with no change in your source. Think of Psyco as a kind of just-in-time (JIT) compiler, a little bit like what exists for other languages, that emit machine code on the fly instead of interpreting your Python program step by step. The difference with the traditional approach to JIT compilers is that Psyco writes several version of the same blocks (a block is a bit of a function), which are optimized by being specialized to some kinds of variables (a "kind" can mean a type, but it is more general). The result is that your unmodified Python programs run faster. Benefits 2x to 100x speed-ups, typically 4x, with an unmodified Python interpreter and unmodified source code, just a dynamically loadable C extension module. Drawbacks Psyco currently uses a lot of memory. It only runs on Intel 386-compatible processors (under any OS) right now. There are some subtle semantic differences (i.e. bugs) with the way Python works; they should not be apparent in most programs.

Neat script I wrote for a friend to annotate a Python script with the types observed during a run of the program

I love python for its beautiful code and practicality. But it’s not going to win a pure speed race with most languages. Most people think of speed and ease-of-use as polar opposites - probably because they remember the pain of writing C. Cython tries to eliminate that duality and lets you have python syntax with C data types and functions - the best of both worlds. Keeping in mind that I’m by no means an expert at this, here are my notes based on my first real experiment with Cython:

 > According to the fact that all Thread run on the same CPU (if i didn't  > understand wrong), i'm asking if python will suffer from the future  > multicore CPU. Will not python use only one core, then a half or a  > quarter of CPU ? It could be a serious problem for the future of python... I agree that it could potentially be a serious hindrance for cpython if "multiple core" CPUs become commonplace. This is in contrast to jython and ironpython, both of which support multiple-cpu parallelism. Although I completely accept the usual arguments offered in defense of the GIL, i.e. that it isn't a problem in the great majority of use cases, I think that position will become more difficult to defend as desktop CPUs sprout more and more execution pipelines. I think that this also fits in with AM Kuchling's recent musing/thesis/prediction that the existing cpython VM may no longer be in use in 5 years, and that it may be superceded by python "interpreters" running on top of other VMs, namely the JVM, the CLR, Smalltalk VM, Parrot, etc, etc, etc. http://www.amk.ca/diary/archives/cat_python.html#003382 I too agree with Andrew's basic position: the Python language needs a period of library consolidation. There is so much duplication of functionality out there, with the situation only getting worse as people re-invent the wheel yet again using newer features such generators, gen-exps and decorators.