Develop Reference

Python vs IronPython for BitCoin Development [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Been looking at porting a BitCoin Mining Pool server across to IronPython
Apart from the limitations of Ironpython supporting upto Python ~v2.7
Is a Ironpython/windows platform really not suited to this type of high volume/large transactional system
What are some of the other limitations I might encounter or should i juts bite the bullet and build up an ubuntu programming RIG
If the later what would be an easy IDE for someone coming from a c# Visual Studio world
Thanks in Adavnce

Without knowing how your existing code is built, or how you intend the new version to work, it's hard to answer specifically, but I can give some generalities.
IronPython limitations/issues, in decreasing order of importance:
* No third-party C extension modules. If you depend on any, you'll have to find a .NET equivalent or reimplement the same thing yourself. If not, not a problem.
* No 3.x. If you know 3.x, Unicode is a lot easier, yield from rocks, etc., and 3.x keeps improving (and even speeding up), while 2.x is stagnant. But how much this is worth is a matter of personal preference, not something anyone else can give you an objective answer on.
* No third-party pure Python modules that rely (in important ways) on refcounting semantics. There aren't too many of these out there, but if you need one, you need it.
* There are a handful of differences between IronPython and CPython, listed in the release notes. Probably none of these will affect you, but you should check.
* If there's any heavy application logic (as opposed to all of the work being networking/files/database), IronPython is much faster than CPython at a few things and much slower at a few others, so you probably need to profile and perf-test before you go too far down either path. (And consider at least PyPy, if not Jython, while you're at it…) But usually this isn't an issue for servers.
Next, is a Windows platform suited to a high-volume systems? Windows is definitely capable of handling thousands of connections per second (or requests, or bytes, or whatever's most relevant to your use case). It will probably never beat linux in pure connections/second/$, but you have to realistically trade off operational costs vs. dev costs. However, oversimplifying a bit, Windows sucks at reactors and rocks at proactors, while linux rocks at reactors and is decent at proactors (and there are other similar issues—e.g., substitute processes/threads for the above). So, even though Windows can do nearly as well as linux in general, it can't do as well on the same code, or often even the same designs. You need to architect your code to take advantage of Windows features and take into account Windows weaknesses. And if you're using a framework to do the heavy lifting for you, there are going to be fewer choices, and the best ones may not work like what you're used to, which is usually a much higher dev cost than changing platforms.
If you do go with CPython on linux, what IDE should you use? Stick with Visual Studio. You can, and probably should, write either all or most of your code in a cross-platform way that runs on both IronPython and linux CPython. Then you can code, test, and debug with Iron Python in Visual Studio, use native Windows CPython and/or Cygwin CPython for occasional sanity checks, and only touch linux for performance tests, final acceptance tests before releases, and debugging problems you can't repro on Windows. You'll still occasionally need a simple text editor on linux, but IDLE, or whichever of vi-vs.-emacs you prefer, or whichever GUI text editor your linux distro comes with as the default will be fine.
If your application logic is tightly coupled with your reactor design or something, this could be difficult. If it's doable, it's probably worth doing, but if it's not… well, you can still use Visual Studio as an editor and project organizer, even if the actual code is intended to be run on a linux box. You don't get the nifty debugger integration, etc. that way, but you still get a lot of mileage.

If I use QT For Windows, will my application run great on Linux/Mac/Windows?

I'm under the impressions that Python runs in the Triforce smoothly. A program that runs in Windows will run in Linux. Is this sentiment correct?
Having said that, if I create my application in QT For Windows, will it run flawlessly in Linux/Mac as well?
Thanks.

Yes. No. Maybe. See also: Java and "write once, run anywhere".
Filesystem layout, external utilities, anything you might do with things like dock icons, character encoding behaviors, these and more are areas you might run into some trouble.
Using Qt and Python, and strenuously avoiding anything that seems tied to Windows-specific libraries or behaviors whenever possible will make running the application on Mac and Linux much easier, but for any non-trivial application, the first time someone tries it, it will blow up in their face.
But through careful choice of frameworks and libraries, making the application work cross-platform will be much more like bug fixing than traditional "porting".

As other posters mentioned, the key issue is making sure you never touch a different non-Qt non-cross-platform API. Or really even a different non-Qt crossplatform API, if you use Qt you kind of need to commit to it, it's a comprehensive framework and for the most part sticking with Qt is easier than going to anything else. There's some nice advantages as the basic primitives in your program will work the same way all over the place. (i.e. a QString in your networking code will be the same as a QString in your interface code.) Portability-wise, if you stay within the API Qt provides you, it should work on multiple platforms.
There will be areas where you may need to call some Qt functions which provide specific cross-platform tweaks more important to some platforms than others (e.g. dock icons) and you won't immediately have a polished application on all three platforms. But in general, you should remain very close to an application that compiles and runs on all three. (Try to use qmake or a similar build system too, as the build process for Qt applications varies depending on the platform. Different flags, etc.)
There's some odd issues that come up when you mix Qt with other APIs like OpenGL, in particular the way windows locks GL contexts differs from the way OS X and Linux does, so if you intend to use OpenGL with multiple threads, try to periodically compile on the other platforms to make sure nothing is completely busted. This will also quickly point out areas where you might have inadvertently used a non-cross-platform system API.
I've used Qt with a team to build a multi-threaded 3-d multiplayer real-time networked game (read: non-trivial application that fully utilized many many areas of Qt) and we were nothing but blown away by the effectiveness of Qt's ability to support multiple platforms. (We developed on OS X while targeting Windows and I regularly made sure it still ran on Linux as well.) We encountered only a few platform specific bugs, almost all of which arose from the use of non-Qt APIs such as OpenGL. (Which should really tell you something, that OpenGL was more of a struggle to use cross platform than Qt was.)
At the end of the experience we were pleased at how little time we needed to spend dealing with platform-specific bugs. It was surprising how well we could make a GUI app for windows given almost none of the team actually used it as a primary development platform through the project.
But do test early and often. I don't think your approach of writing an entire application and then testing is a good idea. It's possible with Qt, but unlikely if you don't have experience writing portable code and/or are new to Qt.

Yes. The code that you write using Qt will work on Windows, Mac, Linux/X11, embedded Linux, Windows CE and Symbian without any change.
You can take a look here.

Generally - as long as you don't use code that is not covered by Qt classes - yes.
I have several time just recompiled applications I wrote in Linux(64bit) under Windows, and the other way arround. It works for me every time.
Depends on your needs, you might also find compiler problems, but I am sure you will know how to work around them. Other people mentioned some issues you should look for, just read the other posts in the question.

It might run well, but it will take some testing, and of course Qt only handles the GUI portability, not the myriad of other things that might cause portability problems.
Qt apps generally don't fit in very well on MacOS because they don't have Applescript support by default and don't necessarily have the right keybindings. But if you do the work to fix those issues, they work, but not nicely. On the Mac, it's far better to build a native UI. If this is an in-house app, Qt is probably OK, but if it's for sale, you won't make many sales and will create yourself some support hassles.

As the others said, everything which is done using Qt-Functionality will most likely run quite flawlessly, WHEN you dont use platform specific functionality of qt.
There isnt that much (most of it has to do with window-manager stuff) , but some things might not work on other systems.
But such things are surely mentiond in the documentation of Qt.
Still there are things which cant be done using Qt, so you will have to do that yourself using plain Python...
Yeah "Python" itself is platform-independent (well it should), but there are lots of other things involved ... well mainly the OS.
And how the OS reacts you will plainly have to findout yourself by testing the application on all target OS.
Recently i wrote an quite simple GUI-application, while it ran flawlessy on Windows, it didnt run on Linux, because on Linux Python interpreted files encoded in unicode differently than on Windows.
Additionally a small script which should return the hostname of the machine, which it did on Windows, only returned "localhost" on Linux, which was obviously not what i wanted.

Using Jython with Django?

I am planning to use Jython with Django. I want to know how stable the Jython project is, how easy to use it is, and how large its developer community is.

Django is proven to work with Jython:
Special focus in Jython 2.5 was to make it compatible with modern web frameworks like Django
There is also a special project, django-jython, that focuses on making database backends and extensions available for Jython development.
There is explicit documentation on how to run Django on Jython
In theory, Jython is 100% compatible with CPython. In practice, some extensions or libraries may have badly written code that make them dependent on a specific Python implementation such as CPython. The django-jython project explicitly provides a tested solution to overcome this problem. Of course you can still run across some libraries that explicitly require CPython (hence mostly safe).

I have not used Django with Jython, so I can't speak to that specific issue, but I've used Jython for other things and I've found it quite stable of late, and just as easy as plain Python. I believe the "core committers" in Jython are substantially fewer than in C-Python (maybe 1/3 the number or less), if that's what you mean by "developer community", but I'm not quite sure what's the point in asking about this -- are you considering joining either developer community (Jython or Core Python) and wondering where you could have the best impact?
If that's the case, I think the key issue isn't really how many others are already helping out, but, "what do you bring to the party" -- if you're a JVM wizard, or an expert at any important Java framework, you could be a real boon to the Jython community while that same skill would help much less in the C-Python community; vice versa, if you're a wizard, say, with autoconfigure and C-coded system calls, that would be precious for the C-Python community, but not as useful for the Jython community.

I use Jython in testing and rapid-development.
From my point of view it is stable.

Pros and cons of IronPython and IronPython Studio

We are ready in our company to move everything to Python instead of C#, we are a consulting company and we usually write small projects in C# we don't do huge projects and our work is more based on complex mathematical models not complex software structures. So we believe IronPython is a good platform for us because it provides standard GUI functionality on windows and access to all of .Net libraries.
I know Ironpython studio is not complete, and in fact I had a hard time adding my references but I was wondering if someone could list some of the pros and cons of this migration for us, considering Python code is easier to read by our clients and we usually deliver a proof-of-concept prototype instead of a full-functional code, our clients usually go ahead and implement the application themselves

My company, Resolver Systems, develops what is probably the biggest application written in IronPython yet. (It's called Resolver One, and it's a Pythonic spreadsheet). We are also hosting the Ironclad project (to run CPython extensions under IronPython) and that is going well (we plan to release a beta of Resolver One & numpy soon).
The reason we chose IronPython was the .NET integration - our clients want 100% integration on Windows and the easiest way to do that right now is .NET.
We design our GUI (without behaviour) in Visual Studio, compile it into a DLL and subclass it from IronPython to add behaviour.
We have found that IronPython is faster at some cases and slower at some others. However, the IronPython team is very responsive, whenever we report a regression they fix it and usually backport it to the bugfix release. If you worry about performance, you can always implement a critical part in C# (we haven't had to do that yet).
If you have experience with C#, then IronPython will be natural for you, and easier than C#, especially for prototypes.
Regarding IronPython studio, we don't use it. Each of us has his editor of choice (TextPad, Emacs, Vim & Wing), and everything works fine.

There are a lot of reasons why you want to switch from C# to python, i did this myself recently. After a lot of investigating, here are the reasons why i stick to CPython:
Performance: There are some articles out there stating that there are always cases where ironpython is slower, so if performance is an issue
Take the original: many people argue that new features etc. are always integrated in CPython first and you have to wait until they are implemented in ironpython.
Licensing: Some people argue this is a timebomb: nobody knows how the licensing of ironpython/mono might change in near future
Extensions: one of the strengths of python are the thousands of extensions which are all usable by CPython, as you mentioned mathematical problems: numpy might be a suitable fast package for you which might not run as expected under IronPython (although Ironclad)
Especially under Windows you have a native GUI-toolkit with wxPython which also looks great under several other platforms and there are pyQT and a lot of other toolkits. They have nice designer like wxGlade, but here VisualStudio C# Designer is easier to use.
Platform independence (if this is an issue): CPython is ported to really a lot of platforms, whereas ironpython can only be used on the major platforms (recently read a developer was sad that he couldn't get mono to run under his AIX)
Ironpython is a great work, and if i had a special .NET library i would have to use, IronPython might be the choice, but for general purpose problems, people seem to suggest using the original CPython, unless Guido changes his mind.

The way you describe things, it sounds like you're company is switching to Python simple for the sake of Python. Is there some specific reason you want to use Python? Is a more dynamic language necessary? Is the functional programming going to help you at all? If you've got a perfectly good working set of tools in C#, why bother switching?
If you're set on switching, you may want to consider starting with standard Python unless you're specifically tied to the .NET libraries. You can write cross platform GUIs using a number of different frameworks like wxPython, pyQt, etc. That said, Visual Studio has a far superior GUI designer to just about any of the tools out there for creating Python windowed layouts.

Are there problems developing Django on Jython?

The background
I'm building a fair-sized web application with a friend in my own time, and we've decided to go with the Django framework on Python. Django provides us with a lot of features we're going to need, so please don't suggest alternative frameworks.
The only decision I'm having trouble with, is whether we use Python or Jython to develop our application. Now I'm pretty familiar with Java and could possibly benefit from the libraries within the JDK. I know minimal Python, but am using this project as an opportunity to learn a new language - so the majority of work will be written in Python.
The attractiveness of Jython is of course the JVM. The number of python/django enabled web-hosts is extremely minimal - whereas I'm assuming I could drop a jython/django application on a huge variety of hosts. This isn't a massive design decision, but still one I think needs to be decided. I'd really prefer jython over python for the jvm accessibility alone.
Questions
Does Jython have many limitations compared to regular python? Will running django on jython cause problems? How quick is the Jython team to release updates alongside Python? Will Django work as advertised on Jython (with very minimal pre-configuration)?
Decision
Thanks for the helpful comments. What I think I'm going to do is develop in Jython for the JVM support - but to try to only use Python code/libraries. Portability isn't a major concern so if I need a library in the JDK (not readily available in python), I'll use it. As long as Django is fully supported, I'm happy.

Django does work on Jython, although you'll need to use the development release of Jython, since technically Jython 2.5 is still in beta. However, Django 1.0 and up should work unmodified.
So as to whether you should use the regular Python implementation or Jython, I'd say it's a matter of whether you prefer having all the Java libraries available or all of the Python libraries. At this point you can expect almost everything in the Python standard library to work with Jython, but there are still plenty of third-party packages which will not work, especially C extension modules. I'd personally recommend going with regular Python, but if you've got a ton of JVM experience and want to stick with what you know, then I can respect that.
As for finding Python hosting, this page might be helpful.

I'd say that if you like Django, you'll also like Python. Don't make the (far too common) mistake of mixing past language's experience while you learn a new one. Only after mastering Python, you'll have the experience to judge if a hybrid language is better than either one.
It's true that very few cheap hostings offer Django preinstalled; but it's quite probable that that will change, given that it's the most similar environment to Google's app engine. (and most GAE projects can be made to run on Django)

I have recently started working on an open source desktop project in my spare time. So this may not apply. I came to the same the question. I decided that I should write as much of the code as possible in python (and Django) and target all the platforms CPython, Jython, and IronPython.
Then, I decided that I would write plugins that would interface with libraries on different implementations (for example, different GUI libraries).
Why? I decided early on that longevity of my code may depend on targeting not only CPython but also virtual machines. For today's purposes CPython is the way to go because of speed, but who knows about tomorrow. If you code is flexible enough, you may not have to decide on targeting one.
The downside to this approach is that you will have more code to create and maintain.

Django is supposed to be jython-compatible sinc version 1.0.
This tutorial is a bit outdated, but from there you can see there are no special issues.