I'm learning programming and have been working with Ruby and ROR, but feel I like Python's language better for learning programming. Although I see the beauty of Ruby and Rails, I feel I need a language more easy to learn programming concepts, thus Python. However, I can't seem to find a community online or offline that work on Apple osx; mostly seems to be PC people for Python. What I like about Ruby is that there is a lot of books, communities, etc, and they tend to have a good amount of Mac resources. Would someone be able to point me to an google groups, forums, etc for beginner Python programming that may have tutorials, or help for people running on Mountain Lion? I'm feeling a little frustrated and caught between the Ruby Vs. Python paradigm, and just want some mac specific resources working with latest Python and eventually Django.
Thanks for any help you may be able to offer!
Mac OS X 10.8 comes bundled with Python 2.7.2 found at /usr/bin/python. Generally in the Python world your operating system is abstracted away, so there aren't that many OS-specific communities. Apple fully embraces Python, however, and you can even write fully native applications using Python.
My suggestions to get you started would be to:
Install homebrew - This is an open source package installer for Mac OS X, inspired by Debian's apt-get or RedHat's yum. This will allow you to easily install many of the system-level dependencies like database servers, NoSQL servers, system libraries, and so on. You will inevitably be required to install this stuff as time goes by, so it's best to have the right tool for the job!
Install pip - The Python package installer. You won't regret it. This will allow you to easily manage external Python packages.
Check out the official Python tutorial. It's quite good, but also assumes you have at least basic understanding of programming.
Check out Learn Python the Hard Way, a free e-Book by Zed Shaw, which assumes no prior programming experience and is very, very easy to follow.
These should keep you busy for a while!!
Related
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.
Does anybody have experience installing PythonSDK (2.7.2) from Conceptive Engineering using their linux package?
Windows version had an installer and went great. Would like to now use on linux box also.
The linux version ships as an archive. It does not seem to be organized like a typical python installation site. No docs/readme/executables in the top level (so seemingly no installer scripts).
Their tech support is kinda slow and docs are slim. Was hoping someone had personal experience.
Thanks
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.
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.
I am about to start my A-Level Computing project (High School Level) which will hopefully be a point-of-sale application for Mac OS. Unfortunately, Objective-C is a little out of my league at the moment and should I get stuck with it in the project I have no one to help out so I would fail the section of the course and not get into University. So this is quite important to me.
I want to use Python to develop a Cocoa app. I know that I need PyObjc, however all details on the net seem to assume it is pre-installed. Apparently this is the case with Leopard and Snow Leopard but I don't seem to have it on Snow Leopard and never noticed it on Leopard. Also, I have tried installing the latest beta of PyObjc by following the instructions on the Sourceforge page, but with no luck.
I would really appreciate it if anyone could shed some light on what needs to be installed, how, and links to any resources or tutorials that could help me.
Thanks in advance for the help!
Update: I see that this is a popular question, I just got the 'Notable Question' badge for it so I thought I would update anyone coming to this page on what I did after getting the answers.
Unfortunately, I wasn't able to use Python to create a Mac application. This was rather disappointing at the time, but probably a good thing. I made a Windows app in C# for my project, it was a tool for creating and running Assembly apps in a simulated environment. My course teacher has now started to use my tool to teach the course instead of his own! I got a very high score on the computing project (over 90%) and this contributed to me getting an A* in my computing A-Level (the highest grade available) and I consequently got in to Southampton University to study Computer Science.
This summer, I decided to make an iPad app (soon to be released) and I am glad to say that I know think I could make a Mac OS application in Objective-C as I feel I have learnt enough. I am glad that I took the time to learn it, it is a great language and really useful with iOS becoming so popular.
Sorry for all the boasting, but I am really happy about it. What I really want to say is, if you are coming to this page hoping to use PyObjc to create Mac apps easily, don't bother. It takes some time and some effort, but once you have learnt Objective-C, it is really satisfying to create apps with it. Good Luck!
Allow me to echo what has already been said. I too am a student who just started a Cocoa development project, and at the beginning I thought "Well, I already know Python, I'll just use PyObjC and save myself from having to learn Objective-C, which looks beyond my grasp." I learned quickly that it can't be done. You can develop for OS X without learning Objective-C, but not without learning the Cocoa libraries, which constitute 99% of what you need to learn to write a Cocoa app in Objective-C. Objective-C itself isn't that hard; it's the Cocoa libraries that you need to invest in learning.
PyObjC basically uses Cocoa libraries and Python syntax. I gave up with it quickly and decided that if I was going to have to learn Cocoa, I may as well use Objective-C.
If you're looking to learn, Aaron Hillegass's book is a good place to start. Good luck!
You mean like Checkout? :-) I only mention it because Checkout is gorgeous and written with PyObjC...
Your concerns are valid, although probably not as much of a potential showstopper as you'd think. Using PyObjC still requires you to learn some Objective-C, and definitely requires you to understand at least some of the Cocoa frameworks, since you need to call into the Cocoa frameworks whenever you need to do some sort of Cocoa-specific task.
I recommend you read and consider the SO question "Why is the PyObjC documentation so bad?" and "PyObjc vs RubyCocoa for Mac development: Which is more mature?" before you completely convince yourself that "just PyObjC" will make things much easier. I refuse to disparage PyObjC because it is quite powerful and incredibly useful, but realize that nothing is a silver bullet, and no language or technology is best for all problems.
The Objective-C language is simple and pretty straightforward. The Cocoa frameworks generally dominate the learning curve for new Cocoa programmers. Plus, you have StackOverflow and lots of other resources to help answer your questions. (Judging by the activity of the "pyobjc" tag, you also stand a better chance of getting good Objective-C help on SO.)
And as one of the Checkout developers I'll weigh in too (hi Quinn!). From what we've seen PyObjC runs fairly well on Snow Leopard. We've built one of the latest SVN revisions 2.2b with some customizations on Leopard and just moved over the site-packages folder.
Theoretically you should be able to use the built in Python/PyObjC (just do import objc, Foundation, AppKit) but as we ship/work with custom versions of both Python and PyObjC I'm not sure what the status exactly is. The mailing list doesn't mention a lot of people having issues (just a few) so that could be a good sign.
Good luck with the project, and if you have specific POS questions shoot me an email ;-)
I hardly use PyObjC myself, but I believe you need to run the Xcode installer on the Snow Leopard DVD in order to use PyObjC.
Also, as Quinn said, you will need to understand at least some Objective-C in order to use a Cocoa bridge like PyObjC without tearing your hair out. It just doesn't insulate you that completely.
I'm going to agree with Quinn here. Even if you're already proficient in Python, learning how to interface Python and Cocoa is not going to be any easier than learning Cocoa with Objective-C.
Objective-C is a simple, clean language that is quite easy to grok. Building the GUI and hooking it up to the back-end will be harder than learning the Objective-C to write the back-end, and building the GUI and hooking it up isn't that hard.
Follow the Cocoa app tutorial (you should be able to get through it in a day, or maybe a weekend if you go slow) and you'll be well on your way.
I'm a long time python developer who's been doing iPhone apps for awhile now (and only using my python knowledge to package up build files for the apps in run scripts), then who started making some PyObjC apps.
I'd have to say, PyObjC is pretty much STILL having to learn objective C (which I already know via iPhone dev), however you get several pretty cool benefits if you use it instead
Easy use of python libraries you know (faster for you)
Option to drop it and go to wxPython if styimied by Cocoa
Somewhat faster development time (you're writing less code, and the translation between the two languages is pretty darn easy to get used to).
Additionally, interface builder is a little tricky to get used to comparatively speaking, but if you're a python dev, it's not like you're exactly used to a functional gui builder anyhow :oP