Is there a difference in python programming while using just python and while using pypy compiler? I wanted to try using pypy so that my program execution time becomes faster. Does all the syntax that work in python works in pypy too? If there is no difference, can you tell me how can i install pypy on debian lunux and some usage examples on pypy? Google does not contain much info on pypy other than its description.
From the pypy features page:
PyPy 1.9 implements Python 2.7.2 and runs on Intel x86 (IA-32) and
x86_64 platforms, with ARM and PPC being underway. It supports all of
the core language, passing the Python test suite.
This means that pretty much any code that you've written in Python 2.7 will work. The only exceptions worth mentioning are some python extensions written in C, such as numpy.
Installation should be fairly easy, you can download a linux binary from here. Then simply extract the interpreter. From this point, you can run your python programs similar to how you would run them with the normal python interpreter.
At the command line, instead of:
python my_program.py
Use:
path/to/where/you/installed/pypy my_program.py
For examples of how/why you might want to use pypy, check out this video from PyCon 2012.
pypy is a compliant alternative implementation of the python language. This means that there are few (intentional) differences. One of the few differences is pypy does not use reference counting. This means, for instance, you have to manually close your files, they will not be automatically closed when your file variable goes out of scope as in CPython.
Related
This is an obvious question, that I haven't been able to find a concrete answer to.
Is the Python Byte-Code and Python Code itself interpreter independent,
Meaning by this, that If I take a CPython, PyPy, Jython, IronPython, Skulpt, etc, Interpreter, and I attempt to run, the same piece of code in python or bytecode, will it run correctly? (provided that they implement the same language version, and use modules strictly written in Python or standard modules)
If so, is there is a benchmark, or place where I can compare performance comparison from many interpreters?
I've been playing for a while with CPython, and now I want to explore new interpreters.
And also a side question, What are the uses for the others implementations of python?
Skulpt I get it, browsers, but the rest? Is there a specific industry or application that requires a different interpreter (which)?
From https://docs.python.org/3/library/dis.html#module-dis
Bytecode is an implementation detail of the CPython interpreter. No
guarantees are made that bytecode will not be added, removed, or
changed between versions of Python. Use of this module should not be
considered to work across Python VMs or Python releases.
On the other hand, Jython "consists of a compiler to compile Python source code down to Java bytecodes which can run directly on a JVM" and IronPython compiles to CIL to run on the .NET VM.
The purpose is to better integrate into your programming environment. CPython allows you to write C extensions, but this is not necessarily true of other implementations. Jython allows you to interact with Java code. I'm sure similar is true of IronPython.
If so, is there is a benchmark, or place where I can compare
performance comparison from many interpreters?
speed.pypy.org compares pypy to cpython
I am looking to compile python source code into a binary. I generally use pypy for performance reasons (my application runs significantly faster using pypy). I found this answer from 2012 stating compiling pypy into binary isn't possible using any of the existing tools (e.g. pyinstaller). Compile PyPy to Exe. I wasn't quite able to follow what the top response was explaining as a solution.
I am wondering:
Is there now a reasonably easy way to compile python code to binary using pypy as the interpreter?
I don't actually need to use pypy, I just use it for the performance gains. Is there a reasonable way to avoid using pypy but still get similar performance gains? This would still need to support compiling to binary.
As an additional note, I use the 2.7 syntax.
you can take a look to nuitka ( http://nuitka.net/doc/user-manual.html)
nuitka --standalone --recurse-on --python-version=2.7 main.py
Frank Wierzbicki in his blog post has written "Jython 2.7b3 brings us up to language level compatibility with the 2.7 version of CPython."
Does it mean that any CPython 2.7 code would work with Jython?
I have a large code written in CPython 2.7. Since we want to integrate it with JAVA modules, I would be extremely interested in a way of migrating to Jython without rewriting of code. Considering libraries, I use a lot of lxml which (as described here) was not compatible with the previous versions Jython.
No, not all code that works in CPython 2.7 will work in Jython, in the same way that some code is tied to a specific OS and won't work on other OS-es (e.g. Windows-specific Python code won't work on Linux, and vice versa).
The syntax will work, but if the script requires specific add-on modules such as lxml, then those will not work. That is because lxml is a C-API extension, and Jython doesn't support the Python C-API.
Similarly, if your code uses the multiprocessing module, then it also won't work on Jython, because that part of the standard library is not included.
Basically, I am a Java programmer who wants to learn Python language. I want to clarify why some of python libaries are distributing using non-portable manner.
Let me explain my thoughts. If someone creates a regular library using Java he prepares 1 (one) JAR file which can be used on different platforms:
my-great-lib-1.2.4.jar
I can use this lib (the same file) on any version of Windows or Linux.
In contrast to Java, python libraries may look like this:
bsdiff4-1.1.4.win-amd64-py2.5.exe
bsdiff4-1.1.4.win-amd64-py2.6.exe
bsdiff4-1.1.4.win-amd64-py2.7.exe
bsdiff4-1.1.4.win-amd64-py3.2.exe
bsdiff4-1.1.4.win-amd64-py3.3.exe
bsdiff4-1.1.4.win32-py2.5.exe
bsdiff4-1.1.4.win32-py2.6.exe
bsdiff4-1.1.4.win32-py2.7.exe
bsdiff4-1.1.4.win32-py3.2.exe
bsdiff4-1.1.4.win32-py3.3.exe
See full list on page.
It looks very strange for me. Even 32bit and 64bit platforms require different installers. Installers! Why do I need an installer in order to use one library? Moreover, outlined installers are only for Windows. Each of them is bind to particular python version. Where is portability?
Could anyone explain a necessity of 10 different files above?
In general, Python libraries are portable across platforms. Problems appear between different major Python versions (3 introduced some big changes from 2, but 2.7 is backwards compatible with 2.6) or when you use C code for optimizing CPU intensive code. On Linux, compiling it yourself is not a problem, when you call pip install package, it will do it for you. The problem is on Windows, where it is much more difficult to compile a C program, especially because not everybody has a compiler. So, for Windows, packages that need something in C, you usually get an installer.
Also, installers are used because they set up everything nicely, look in the registry for the appropriate place to put everything, offer a standard way to uninstall them (the ones from Chrisopther Goelke's site can be removed using Add/Remove programs in Control Panel) and because that's the standard on Windows: most of the programs on Windows are installed via an exe, because it doesn't have a standard and widespread package manager.
All these libraries are then portable: you can use them from any platform, but installing them is what differs.
There are many complications. In Java where your code and then byte-code is interpreted by JVM, the inherent computer architecture do not play lot of role as long as your code is interpreted well by JVM. In fact, that is one of the primary reason Java got so popular because your code should only worry about rightly compiled by JVM.
However, in Python situation is different. I am trying to summarize some of the reason which I think is important in following lines:
The language itself is evolving (although it is long in the scenario if you think!) and changes are happening inside the language. New features are added and sometime, even some remodeling of language is done ( Python 2.x to Python 3.x)
Python relies heavily on its C extensions and so does the applications written in Python. If you write a python program and have some CPU intensive code, you can choose to write it in C. This also adds in the necessity of creating number of libraries for various distribution.
For one python versions jump around. In python 3, the syntax of some builtins completely changed. For example:
raw_input()
changed to:
input()
also, a lot of the standard library has changed even in the alpha of 3.4. As for the 32/64 bit question, I cannot fully answer. I know that certain platforms have trouble when trying to run 32/64, and that may be the point there.
I'm looking to call Python code from Ruby. There are a few existing tools to do this and a few questions on this site recommending http://rubypython.rubyforge.org/, which works by embedding the Python interpreter in Ruby. I'm working on an app that uses libraries unique to Python (namely graph-tool, which I have reasons for using over, say RGL), but the final project is in Rails so having Ruby code do the controlling work would be ideal. I want it to be speedy so I'm using PyPy. Is there a way to get the PyPy interpreter embedded in Ruby code, or to make the Python interpreter in rubypython run PyPy?
No. Well, not without a lot of work.
First, RubyPython doesn't really include an embedded Python interpreter; it just wraps the interpreter at runtime. As shown in the docs, you can run it with any Python you want, e.g.:
>> RubyPython.start(:python_exe => "python2.6")
So, what happens when you try?
>> RubyPython.start(:python_exe => "/usr/local/bin/pypy")
RubyPython::InvalidInterpreter: An invalid interpreter was specified.
from /Library/Ruby/Gems/1.8/gems/rubypython-0.6.3/lib/rubypython.rb:67:in `start'
from /Library/Ruby/Gems/1.8/gems/rubypython-0.6.3/lib/rubypython/python.rb:10:in `synchronize'
from /Library/Ruby/Gems/1.8/gems/rubypython-0.6.3/lib/rubypython/python.rb:10:in `synchronize'
from /Library/Ruby/Gems/1.8/gems/rubypython-0.6.3/lib/rubypython.rb:54:in `start'
from (irb):4
Unfortunately, it requires CPython 2.4-2.7. It doesn't work with CPython 3.x, PyPy, Jython, etc. Again, from the docs:
RubyPython has been tested with the C-based Python interpreter (cpython), versions 2.4 through 2.7. Work is planned to enable Python 3 support, but has not yet been started. If you’re interested in helping us enable Python 3 support, please let us know.
Without looking at the code, I'm guessing rubypython is using rubyffi to either:
* Wrap the CPython embedding APIs, or
* Directly call CPython VM internals via its dll/so/dylib exports.
If it's the former, the project might be doable, but still a lot of work. PyPy doesn't support CPython's embedding APIs. If it had its own embedded APIs, you could potentially rewrite rubypython's lower level to wrap those instead, and leave the higher-level code alone. But embedding PyPy at all is still a work in progress, (See http://mail.python.org/pipermail/pypy-dev/2012-March/009661.html for the state of affairs 6 months ago.) So, you'd need to first help get PyPy embedding ready for prime time and stable, and then port the lower level of rubypython to use the different APIs.
If it's the latter, you're pretty much SOL. PyPy will never support the CPython internals, and much of what's internal for CPython is actually written in RPython or Python and then compiled for PyPy, so it's not even possible in principle. You'd have to drastically rewrite all of rubypython to find some way to make it work, instead of just porting the lower level.
One alternative is to port Ruby to RPython and use PyPy to build a Ruby interpreter and a Python interpreter that can talk to each other at a higher level; then, writing something like rubypython for PyRuby and PyPy would be trivial. But that first step is a doozy.