What are the downsides of using Python instead of Objective-C? [closed]

Question

I know some Python and I'm really impressed by the language's ease of use. From what I've seen of Objective-C it looks a lot less pretty, but it seems to be the lingua franca for Mac OS X development (which means it has better documentation).

I'm thinking about starting Mac development - will using PyObjC+Python make me a second class citizen?

Antananarivo

Answer 1

Yes.

For one thing, as you note, all the documentation is written for Objective-C, which is a very different language.

One difference is method name. In Objective-C, when you send a message to (Python would say “call a method of”) an object, the method name (selector) and arguments are mixed:

NSURL *URL = /*…*/;
NSError *error = nil;

QTMovie *movie = [QTMovie movieWithURL:URL
    error:&error];

This isn't possible in Python. Python's keyword arguments don't count as part of the method name, so if you did this:

movie = QTMovie.movieWithURL(URL, error = ???)

you would get an exception, because the QTMovie class has no method named movieWithURL; the message in the Objective-C example uses the selector movieWithURL:error:. movieWithURL: and movieWithURL would be two other selectors.

There's no way they can change this, because Python's keyword arguments aren't ordered. Suppose you have a hypothetical three-argument method:

foo = Foo.foo(fred, bar=bar, baz=baz)

Now, this calls foo:bar:baz:, right?

Not so fast. Foo may also have a method named foo:baz:bar:. Because Python's keyword arguments aren't ordered, you may actually be calling that method. Likewise, if you tried to call foo:baz:bar:, you may actually end up calling foo:bar:baz:. In reality, this case is unlikely, but if it ever happens, you would be unable to reliably call either method.

So, in PyObjC, you would need to call the method like this:

movie = QTMovie.movieWithURL_error_(URL, ???)

You may be wondering about the ???. C doesn't allow multiple return values, so, in Objective-C, the error: argument takes a pointer to a pointer variable, and the method will store an object in that variable (this is called return-by-reference). Python doesn't have pointers, so the way the bridge handles arguments like this is that you pass None, and the method will (appear to) return a tuple. So the correct example is:

movie, error = QTMovie.movieWithURL_error_(URL, None)

You can see how even a simple example deviates from what documentation might show you in Objective-C.

There are other issues, such as the GIL. Cocoa apps are only going to get more concurrent, and you're going to want in on this, especially with tempting classes like NSOperation lying around. And the GIL is a serious liability, especially on multi-core machines. I say this as a Python guy myself (when not writing for Cocoa). As David Beazley demonstrates in that video, it's a cold, hard fact; there's no denying it.

So, if I were going to switch away from Objective-C for my apps, I would take up MacRuby. Unlike with PyObjC and RubyCocoa, messages to Cocoa objects don't cross the language bridge; it's a from-the-ground-up Ruby implementation in Cocoa, with language extensions to better support writing Cocoa code in it.

But that's too far ahead of you. You're just getting started. Start with Objective-C. Better to avoid all impedance mismatches between the language you're using and the one the documentation is written for by keeping them the same language.

Plus, you'll find some bugs (such as messages to deceased objects) harder to diagnose without knowledge of how Objective-C works. You will write these bugs as a new Cocoa programmer, regardless of which language you're writing the code in.

So, learn C, then learn Objective-C. A working knowledge of both shouldn't take more than a few weeks, and at the end of it, you'll be better prepared for everything else.

I won't go into how I learned C; suffice to say that I do not recommend the way I did it. I've heard that this book is good, but I've never owned nor read it. I do have this book, and can confirm that it's good, but it's also not Mac-specific; skip the chapter on how to compile the code, and use Xcode instead.

As for Objective-C: The Hillegass book is the most popular, but I didn't use it. (I have skimmed it, and it looks good.) I read Apple's document on the language, then jumped right in to writing small Cocoa apps. I read some of the guides, with mixed results. There is a Currency Converter tutorial, but it didn't help me at all, and doesn't quite reflect a modern Cocoa app. (Modern apps still use outlets and actions, but also Bindings, and a realistic Currency Converter would be almost entirely a couple of Bindings.)

Kale

+1 and respect for the extensive answer – Gutturalize

MacRuby is clearly the "most native" of the bridged languages, but it is still not remotely native. Xcode doesn't support it, you won't be able to look up documentation without translating to Objective-C and asking MacRuby based Cocoa questions will vastly reduce the # of folks that might be able to answer. And it is more unnecessary moving parts given that you need to learn Objective-C anyway to use the Cocoa APIs. – Endocrinology

The GIL is in the process of being fixed. I watched that video and thought "I know how to fix this! At least, a good step towards a solution.". But after getting the Python Subversion repository, I discover that it was merged into Python 3K about 3 months ago. sigh – Confect

I 've been struggling to find some good sources to learn Mac Development (for a beginner), does anyone here know some good sources – Perigee

@Samhan: “anyone” isn't going to work very well in this context: You're commenting on an old answer, so not many people are going to come across this question who don't have the same question; I only saw your comment because it's my answer you commented on. Anyway, to answer your question, I have an answer on that very topic: stackoverflow.com/a/6488745/30461 – Kale

The main problem it seems is that PyObjC is always behind, now that I want to use AVFoundation it is not ready, because Apple is not committed to it but an enthusiastic developer (no matter how great) – Ammoniacal

Answer 2

This really says it all:

As the maintainer of PyObjC for nearly 15 years, I will say it bluntly. Use Objective-C. You will need to know Objective-C to really understand Cocoa anyway and PyObjC is just going to add a layer of bugs & issues that are alien to 99% of Cocoa programmers.

a comment in an answer to this question. This question is also interesting.

Pathogenesis

Honestly, the only good reason to use a bridge is if you really, truly need to do something where you'd be crippled without the dynamic language features. Scripting systems and stuff that needs to follow Postel's law tend to be good examples. But usually, yes, you want Objective-C, painful though it is in comparison. – Austronesia

Answer 3

DO NOT ATTEMPT to avoid learning objective-C if you're going to write apps for the Mac. The purpose of PyObjC and the other language bindings is to let you re-use existing libraries in your apps, not to let you avoid learning the native tools.

Weathering

Answer 4

Second class citizen seems a bit strong. The Objective-C API's are available from Python as well, should you need them, and that's mostly if you want to make Cocoa apps. But then they are restricted to OS X anyway. Personally, I have no interest in building apps that isn't cross-platform, but that's me. That also means I haven't actually done this, so I don't know how tricky it is, but there was an article in the Python Magazine not long ago, and it didn't look that horrible.

The major drawback of Python is execution time, and that mainly comes from it being a dynamic language. This can be solved with Cython and C-extensions, etc, but then you get a mix of Python + ObjectiveC API's + Cython which can be daunting.

So it depends a lot of what kinds of applications you are going to make. Something uniquely OSX-ish that makes no sense anywhere else? ObjectiveC is probably the ticket. Cross-platform servers, well then Python rocks! Something else? Then it depends.

Giza

Answer 5

This is something I've been wondering myself, and although I hope someone comes by with more experience, from what I know you will not be seriously constrained by Python itself. Along with Java and GCC, Python is an excellent way to write native cross-platform applications. Once you get the hang of it you should be able to map example code in Objective C to your Python code.

Since you have access to all libraries and events, everything that you can do in Objective C will be there in Python. Of course, the more OS X-only calls and functions you use, the less easy it will be to port to another platform, but that's beside the point. Usually graphics programming and working with device drivers is somewhat of a limiting factor - but in both cases I'm finding evidence of good support and community libraries (search for Python and Quartz, Lightblue, libhid, PyUSB, for some examples).

The decisive factor for me would be: what is the level of tooling and IDE support that is needed. Apple provides some great software for building new software, but then again with something like Pydev you've got a great place to write Python code too! http://pydev.org/

So give it a try, I'm sure you won't regret it, and there will be a supportive community to draw on for help and insipiration.

Philtre

Answer 6

You're going to need Objective-C: that's what all the tutorials, documentation, sample code, and everything is written in. In addition to a wilder variety of people being able to help you.

So learn ObjC first. If, on your second or third project, or a year down the road, you start a project that needs a Python module (like, say, Twisted, or SQLAlchemy. But a SERIOUS need like foundation of your app need, where the extra boost your app gets makes everything worth it), then you can write a PyObjC app and get a lot of the speed benefits of that language, with your background in Cocoa.

Neona

Answer 7

Just as an extra option, consider that wxPython can produce some pretty good applications on Mac as well as on Linux and Windows. For the most part you can get native appearance but maintain portability with little or no attention to platform-specific issues.

In other words, PyObjC + Python is not the only way to do Mac development with Python.

Gracie

PyObjC + Python is the only way to do Mac development with Python if you want an application that actually looks and feels like a mac app. The wxPython and Tk based applications stick out like sore thumbs. – Endocrinology

@bbum, it's a subjective issue or, if nothing else, the particular examples you've seen have perhaps not been well done. In any case, spewing absolutisms isn't a good way to help the OP... (Note, in a case you weren't aware, that wxPython (and I believe the latest Tk stuff) use native controls for the most part. How that will lead to something that neither looks nor feels native you'd have to explain.) – Gracie

Look native, sure, but not feel native. There are subtle differences simply because wx and Tk have a different model of interaction than Cocoa. And it isn't subjective; it is an observation and conclusion drawn from 20 years of watching Mac apps built with non-native APIs be slammed in reviews. The tools are improving, but there is still an impedance mismatch. – Endocrinology

@bbum, okay, I mistook the "looks and feels" part of your comment to imply both had trouble. I can accept that wxPython currently doesn't feel like Cocoa apps... apparently it's still based on Carbon in the current release. Maybe that will change with the upcoming Cocoa-based release (still in development apparently, as I just heard today). – Gracie

Answer 8

No you dont need to know Objective C you dont need to use PyObjC , and you wont be a second class citizent.

Unless you want to do something extremely specific to the MAC platform , coding in Objective C or using PyObjC is a really bad idea.

The reason is obvious, once you go the objc route you say a big "goodbye" to other platforms. Its that simple.

Apple does not want you to code for other platforms the same way Microsoft does not want you to code for other platforms. And that is why more and more developers are turning to open source languages like, python, java, ruby etc. Because you dont care what Apple and Microsot , you only care about an App that is the most useful and most easy to develop. And making your App available only for MAC will make it less useful and obviously developing in Objective C is way more difficult.

Python has more than enough libraries to accomodate you , hundrends of them , readily available for the mac platform. I for instance develope a new application in pygame, no its not a game, if I have done the same thing in ObjC or PyObj I would have to rewrite the code for windows and linux. While with pygame my code works exactly the same in windows and linux even though my main platform is macos.

Thats the appeal of most python libraries , they are cross platform. WxPython is another example, someone mentioned that "it does not exactly look natively" , do you want this to stop you from making your application available for windows and linux. Why limit yourself only on the MAC platform ? Do you think the average user will care how natively your app will look. Even macos apps do not look native , many of them introduce their own "eye candy" gui. Not that you cant make WxPython look 100% native, the way you code is always importnat.

Objc makes sense when you intend to develop for Iphone OS , as Apple thought it a great idea to exclude python (and not only python), even though they were forced to include javascript (or else websurfing would have being a nightmare on iphoneos) . Pyjamas, can make python available for iphone os as well (with no hacks or jailbroken phones), but with the obvious limitations since it translates python code to javascript, but still its a valid solution till Apple decide that excluding python from iphone os is a really bad idea.

link text

There is no harm done in studying Objective C though. You can always use the native libraries via pyobjc.

But to be absolutely sincere with you, If my app reaches a dead end with the python libraries ( a very unlikely scenario) I would rather wrap an existing cross platform C/C++ Libraries with Cython than go the objective c pyobjc route and detroy the cross platform ability of my app. The last thing I would be using is anything platoform specifc.

Now if you dont care about other platforms at all, then I guess Objective C can be a valid choice. It certainly looks ugly as hell, but I have heard that it gets much better the more you use it and there are many people that prefer it over C/C++.

Teufert

Someone wants to start doing "Mac development" and you wave them off anything platform specific? They showed up asking about platform development. Not helpful, or on topic. – Ibanez

I think you confuse "Mac Development" with "Mac Only Development".I think my answer clearly illustrates that and clearly is on topic. Now if the OP has asked about "Mac ONLY Development" then my answer would be different, but he did not. – Teufert

Occam's Razor: If OP had meant multi-platform development, they would have said so. They didn't; they said "Mac development." Nothing at all in the post - title, body, tags, etc - indicates multi-platform development. To the contrary, it's tagged Cocoa which is explicitly Apple-centric. – Ibanez