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.
Related
I just got Pycharm Community version and Python version2. something. I just wanna know if i can have a problem with the versions. Also What is the best way to use Python for?
PyCharm: Simplifying things a bit, PyCharm is just a fancy editor. Unless you have it deeply ingrained into your workflow, you can always switch to a different editor, should PyCharm cease to fulfill your needs.
Python 2 is not the newest version of the language; that would be Python 3.6 as of now (that is, the summer of 2017). So, theoretically, if you start to write lots and lots of code and then later decide, when Python 2 is no longer maintained and third-party libraries drop their support, that all your code should now be compatible with Python 3, you may find yourself in the uncomfortable situation that you suddenly have to port all your code to Python 3, but you lack the ressources to do so. If you recently started programming in Python and have no prior investment, you might consider using Python 3 instead.
Otherwise, simply write modern Python. If you do a serious project, write unittests. Then porting to Python 3 is doable.
What is the best way to use Python for? Python is a multi-purpose language used in all kinds of contexts. It is often used in the scientific community. But it's also used a lot for web services, in education, as an embedded scripting language and many of other use cases. What are your interests? Just use Python for that.
I've googled and googled, but have found almost nothing in the way of discussions or best practices in managing larger enterprise codebases in Python. Here, I'm simply soliciting any and all pointers to such information. Here's some background and some of the questions I'm looking to answer.
We're long-time Java developers, who have solved similar problems to those mentioned below largely using well established Java best practices, as well as Maven, Ant and a Sonotype Nexus repo.
I'm talking internal software only here. We're not looking to distribute anything Python-based. We've got multiple development groups using Python, each developing sharable utility code libraries, final web applications and stand-alone tools, all in pure Python. Each group has its own Github source repository.
How do we manage our shareable code, both within a group and across groups? Do we create eggs (or something similar) and distribute and install them into the Python system? If so, would we store them in our Nexus repo like our Java jars, or is there a more Python-specific method if internal package distribution? Or, do we just share raw code, checking out sources from multiple Github repos?
If we share raw code, how do we manage getting the Python searchpath right as we bring together code from multiple repositories?
How do we manage package namespaces when we want our packages to all live in a com.ourcompany base namespace? It seems like python isn't too happy when you bring together source trees with overlapping namespaces.
How do we manage third party package versioning? I've never seen easy_install or pip passed a version number. How do we lock down third party package versions?
Do tools exist to aid in Python code reviews, CI, regression testing, etc.?
We're relative newbies to Python code, so some of these questions may have fairly obvious answers. Still, I find it surprising that I can't find more information on managing larger Python codebases.
What issues will we encounter that I haven't thought to ask about, or don't yet know enough to even know to ask about?
Any valuable pointers will be greatly appreciated.
Well, I won't even try to answer all those (excellent) questions, but here are a few opinionated pointers which will hopefully help (as someone who works in both worlds, though more Java).
Packaging
If so, would we store them in our Nexus repo like our Java jars, or is
there a more Python-specific method if internal package distribution?
Or, do we just share raw code, checking out sources from multiple
Github repos?
Packaging in Python is historically a bit of a mess IMHO, though it feels like it's improving. Distutils is the major / native tool here - I've not used it much, feels slightly scary in places. In general, also check recommended tools.
Pip has all but won the war of mindshare, especially when installing 3rd party libraries. I've not solved the local library problem myself, (maybe someone else reading has), but if I were, I'd probably opt for Pip with local/network-disk repos e.g. by installing from wheels.
Another option (which can cause all sorts of hassles itself) is to package in your OS's native packager, be it Debian-style apt or by creating RPMs, etc. Of course, Windows not so much.
Versioning etc
How do we manage third party package versioning? I've never seen
easy_install or pip passed a version number.
Pip
Pip definitely supports version specifiers. Turns out Easy Install does too. I suppose many people / smaller projects opt for latest-and-greatest, which of course isn't always as "appropriate" in the enterprise...
Virtualenv
No discussion of versioning and Python would miss a Python2/3 reference, but I'm sure you're aware of all this already.
More important then would be to mention virtualenv. It truly frees you from the mess you can get in to testing multiple versions, bearing in mind especially that your (*NIX) operating systems typcially rely heavily on Python themselves. It's a big subject so have a look at the docs.
Developer Tooling
Do tools exist to aid in Python code reviews, CI, regression testing,
etc.?
Code Review
Very much so. Most code review tools are multi-language (it's just a formatting issue really), so just pick your favourite enterprise-friendly one, be it Crucible, Github's one (Barkeep?), Gerrit, or whatever.
CI
For CI you have almost as many options again. Running python apps is usually less involved than Java ones, so most CI systems, though often Java-focused, support Python. (FWIW, we use drone.io for Quod Libet). Jenkins should have no problem doing this, and it seems people have done so with TeamCity.
However, the "original" or "most Pythonic" is probably Buildbot, but I've not used it personally. Looks a lot newer than I remember, and it had quite a lot of support in the Python community I think...
Testing
For testing, though not quite as mature as JUnit / TestNG, check out the de-facto / JUnit-like unit testing unittest, but also (nicer?) alternatives like nose.py.
For higher level (BDD) testing, try something like Lettuce - as the name implies heavily inspired by Cucumber, or maybe Behave. I've not tried them, but common opinion is they're less mature than Cucumber / JBehave / Concordion / Rspec etc.
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
Is 2.x still the norm or would you recommend just coding in v3 at this point?
Python 3 is still a long way off having universal support from tools, libraries and distros, so its use in production would depend very much on whether the bits you need (or are likely to need in the near future) have been ported.
For exploratory, educational and other uses, it depends very much on your own proclivity for living on the bleeding edge. If you are happy building from source and debugging and hacking third-party libraries to get things working, then you'll probably have no issues with Python 3. Otherwise, stick to the latest your distro offers, and if it is stuck on a really old Python — CentOS is still on 2.4! — you have my commiserations. Personally, I steer clear of CentOS for precisely this reason.
Google App Engine documentation states it uses Python 2.5
Today I happened to notice that Python Imaging Library is till not released for 3.x.
So, if you need those libraries or services, I guess you should wait.
Do the frameworks and libraries you use have Python 3 versions? Libraries you use for development, and does your deploy stack support Python 3?
Many Python projects have a lot of dependancies, especially web based projects, most of which aren't Py3K ready yet.
If your stack is good, sure - Python 3 is the future, might as well embrace it now.
My main use of Python is Django. Support for 3.x for this framework still lies in the future, unfortunately, and who knows about any related modules - so no, it's not quite time for many people.
I actually bought Python 3 books last year when I started learning Python, thinking "I'll just start with 3 from the beginning!". That didn't work out, though.
I've always used v3 primarily. "Hacking 3rd party libraries" to me is just like importing any other module. The only thing is since most stuff still uses v2 you have to know both versions and keep them straight when looking at others code.
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.