We have an existing C# project based on NHibernate and WPF. I am asked to convert it to Linux and to consider other implementation like Python. But for some reason, they like NHibernate a lot and want to keep it.
Do you know if it's possible to keep the NHibernate stuff and make it work with Python ? I am under the impression that NHibernate is glue code between C# and the DB, so can not be exported to other languages.
Alternative question: can somebody recommend a good python compatible replacement of NHibernate ? The backend DB is Oracle something.
NHibernate is not specific to C#, but it is specific to .NET.
IronPython is a .NET language from which you could use NHibernate.
.NET and NHibernate can run on Linux through Mono. I'm not sure how good Mono's support is for WPF.
I'm not sure if IronPython runs on Linux, but that would seem to be the closest thing to what you are looking for.
There is a Java version of NHibernate (said tongue in cheek) called Hibernate and there are integration points between Java and Python where Linux is very much supported.
I know the Python community has its own ORMs, but as far as I'm aware, those options are not as mature and feature rich as Hibernate/NHibernate.
I would imagine that almost all of the options available to you would support Oracle.
What about running your project under Mono on Linux? Mono seems to support NHibernate, which means you may be able to get away with out rewriting large chunks of your application.
Also, if you really wanted to get Python in on the action, you could use IronPython along with Mono.
SQLAlchemy is the most powerful ORM in Python so far.
Check out Django. They have a nice ORM and I believe it has tools to attempt a reverse-engineer from the DB schema.
Related
I have been wondering if developing Linux kernel modules (drivers) with Python is possible. Is it?
Yes, it is possible:
http://www.kplugs.org/
Although not recommended in production machines, this can be really useful while prototyping your driver.
See here we have certain issues.
We have to understand why Linus Torvalds himself preferred C and Assembly language.C is the only language that won't hinder your performance on raw hardware. The Operating System was designed to use as much minimal resources as possible.
Coming to Python, we already know that it's an interpreted language. So thereby its slow as it runs on a virtual environment.
Yes you can definitely try some. Check this
Instead you can really look forward to filesystem programming and multilevel cache organization and such using python.
No; LKM on Linux have to be compiled down do a specific ELF object code format.
Of course you could make your own hack of Python that does compile down to kernel object code, but as far as I know, at this time there is no such Python publicly available.
As far as I understand Eclipse doesn't provide user with python bindings by default. Nor any projects of such kind was I able to find with google.
Are there any third-party plugins for that? Any tutorial? May be with Jython?..
As far as I know, you need to use Java. Eclipse is written in Java, and even the vanilla application is made up of several Java components glued together by the core plugin loader. Jython might work if:
you can cross-compile Python to Java bytecode (indeed you can, thanks to sayth for pointing that out), and
you can access the Eclipse APIs inside Jython.
So, here's more or less what your plugin's architecture might look like. If you can get at the Eclipse APIs, then you can write most of it in Jython, and then make a Java wrapper for it with the Embedding Jython instructions.
If you can't get the Eclipse functionality into your Jython, then you can still write some of your code in python, and then have the Eclipse API access happening on your Java layer. This will be annoying in proportion to how evenly split your code is between python and Java. I've worked on a project before where we embedded python into C++ (or it might have been the other way around...), and it's a major headache if you don't plan it out right.
in the early nineties I bought the tawk (Thompson awk) compiler and developed since than a lot of programs for my companies. The compiler produces fast reliable code and has a lot of useful extensions for the Windows environment.
Until now it worked in the W95, W2K and XP without problems but now that I have to move to W7 / 2008 Server I am in doubt if it is wise to try to continue with this although excellent but outdated and no more supported product.
My questions to you :
What can you recommend for real-world business applications (all of them run in batch mode - no GUI) ?
Has someone made a bigger transition (manual reprogramming) from xxx (here: awk) to Python ?
What Python implementation should I use ? I need fast file I/O and extensive random access to 100.000+ dictionary elements for 1.5 Mio monthly transactions
Which is the most stable version ? 2.7.x ? 3.1.x ?
Does 3.1 support Windows Automation ? I have to drive the Excel API through COM and need access to MS-SQL
And : is Python really the choice for this kind of task ?
Thank you for your honorable answersMeiki
Python is a good choice for these types of tasks. You should use Python 2.7.2 and since you are on Windows, you may want to use the Activestate Python distribution http://www.activestate.com/activepython/downloads which is standard Python bundled with a number of additional useful libraries and an easy to use package manager named PyPm.
Also, you should have a look at the slide presentations here http://www.dabeaz.com/generators/ and here http://www.dabeaz.com/generators-uk/index.html because Python generators are a powerful way to handle the same types of batch processing that AWK is used for.
As for Windows automation, the Activestate distro for Windows includes this, or you can download and install pywin separately if you are using the Python.org distro. I've used Python and COM to extract data from Word documents, Excel spreadsheets, Outlook mailboxes and Lotus Notes databases among other things.
If you want to stick with the awk style of doing things, you can write some Python helper functions so that your Python programs don't look so foreign to awk eyes. In fact, pyawk.py may already be all that you need http://pyawk.sourceforge.net/ You can download it here http://sourceforge.net/projects/pyawk/files/pyawk/pyawk-0.4/ however be warned that Python has evolved a lot since it was last updated.
Without question this is the best way to add Tawk to Django/python. It solved all my needs.
https://github.com/CleitonDeLima/django-tawkto
I found http://www.iseriespython.com/, which is a version of Python for the iSeries apparently including some system specific data access classes. I am keen to try this out, but will have to get approval at work to do so. My questions are:
Does the port work well, or are there limits to what the interpreter can handle compared with standard Python implementations?
Does the iSeries database access layer work well, creating usable objects from table definitions?
From what I have seen so far, it works pretty well. Note that I'm using iSeries Python 2.3.3. The fact that strings are natively EBCDIC can be a problem; it's definitely one of the reasons many third-party packages won't work as-is, even if they are pure Python. (In some cases they can be tweaked and massaged into working with judicious use of encoding and decoding.) Supposedly 2.5 uses ASCII natively, which would in principle improve compatibility, but I have no way to test this because I'm on a too-old version of OS/400.
Partly because of EBCDIC and partly because OS/400 and the QSYS file system are neither Unix-like nor Windows-like, there are some pieces of the standard library that are not implemented or are imperfectly implemented. How badly this would affect you depends on what you're trying to do.
On the plus side, the iSeries-specific features work quite well. It's very easy to work with physical files as well as stream files. Calling CL or RPG programs from Python is fairly painless. On balance, I find iSeries Python to be highly usable and very worthwhile.
Update (2012): A lot of work has gone into iSeries Python since this question was asked. Version 2.7 is now available, meaning it's up-to-date as far as 2.x versions go. A few participants of the forum are reasonably active and provide amazing support. One of them has gotten Django working on the i. As expected, the move to native ASCII strings solves a lot of the EBCDIC problems and greatly increases compatibility with third-party packages. I enthusiastically recommend iSeries Python 2.7 for anyone on V5R3 or later. (I still strongly recommend iSeries Python 2.3.3 for those who are on earlier versions of the operating system.)
Update (2021): Unfortunately, iSeriesPython is no longer maintained, and the old website and forum are gone. You can still get the software from its SourceForge repository, and it is still an amazingly useful and worthwhile asset for those who are stuck on old (pre-7.2) versions of the operating system. For those who are on 7.2 or newer, there is a Python for PASE from IBM, which should be considered the preferred way to run Python on the midrange platform. This version of Python is part of a growing ecosystem of open source software on IBM i.
It sounds like it is would work as expected. Support for other libraries might be pretty limited, though.
Timothy Prickett talks about some Python ports for the iSeries in this article:
http://www.itjungle.com/tfh/tfh041706-story02.html
Also, some discussion popped up in the Python mailing archives:
http://mail.python.org/pipermail/python-list/2004-January/245276.html
iSeriesPython is working very well.
We are usning it since 2005 (or earlier) in our Development and Production Environments as an utility language, for generating of COBOL source code, generating of PCML interfaces, sending SMS, validating/correcting some data ... etc.
With iSeriesPython you can access the iSeries database at 2 ways: using File400 and/or db2 module. You can execute OS/400 commands and you can work with both QSYS.LIB members and IFS stream files.
IMHO, iSeries Python is very powerful tool, more better than REXX included with iSeries.
Try it!
I got permission to install iSeries Python on a box about 3 years ago. I found that it worked pretty much as advertised. I contacted the developer and he was very good about answering questions. However, before I could think about using it in production, I had to approach the developer regarding a support contract. That really isn't his gig, so he said no and we scrapped the idea. The main limitation I found is that it is several releases behind Python on other platforms.
I have also had very good experience with Jython on the iSeries. Java is completely supported on the iSeries. Theoretically, everything you can do in RPG on the iSeries, you can do in Java, which means you can do it in Jython. I was sending email from an AS/400 (old name for iSeries) via JPython (old name for Jython) and smtplib.py in 1999 or 2000.
Another place to look is on the mailing list MIDRANGE-L or search the archives for the list at midrange.com. I know they have talked about this a while back.
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.