Write Pure Python Cocoa Apps 30
bbum writes "Today, Ronald Oussoren and I patched the PyObjC (PythonObj-C) bridge to allow for completely standalone Cocoa applications that are implemented in Python. My 11-Oct-2002 weblog entries provide more detail and includes a link to a PyObjC Cocoa app that can be downloaded and hacked upon (with the app, you can actually create other apps without using the dev tools at all!). As the days pass, I'll be updating the 'blog with new software, updates, etc. A Fink package will be submitted shortly. (In reality -- Ronald did the hard stuff in that he figured out how to subclass ObjC classes in Python!!)" Nifty. Note there is also a PerlObjCBridge module included with Jaguar, and there's also CamelBones for Perl-Cocoa; what other scripting frameworks for Mac OS X are out there?
When.. (Score:2, Funny)
Re:When.. (Score:2)
Perl-Cocoa... (Score:2)
If I understand correctly... (Score:3, Interesting)
This is different than porting the Tk GUI to Aqua. I know this also is being done for Python.
I would eventually like both.
Re:Perl-Cocoa... (Score:1)
Furthermore, never.
Tk doesn't have the abstraction to allow Tk apps to magically behave like Mac apps. You can make them LOOK like Aqua, but that creates the worst possible combination.
Perhaps this could be used to replace Tk. Non-OS X versions could use GNUStep.
Yeah, good, but ... (Score:3, Insightful)
What on earth is the point of a programming language that you can't write apps in???
There are lots of these "WoW! Now you can use Programming Language X to do Y", but isn't the whole point of programming languages that you can do anything you want with them?
Re:Yeah, good, but ... (Score:5, Informative)
Yes, many languages are very powerful and allow you to do many things, but just because a language exists doesn't mean it magically includes support for everything -- including things that didn't exist at the time the language was created.
Generally, a language has a core set functionality that only provides a framework to build applications. Most languages then have a standard set of libraries implementing common functionality, and extended libraries implementing features outside the spec of the core and common APIs.
Anyway, Cocoa isn't written in Python, so you can't just use it from Python without an interface into the Cocoa framework. So, someone has provided an interface to Cocoa. Its not that Python was semantically unable to work with Cocoa, but that the mechanism didn't exist.
You should try something other than Visual Basic, maybe you'd learn about how software really works.
Re:Yeah, good, but ... (Score:2, Informative)
Programing languages CAN be used to do (almost) anything, but they're not all DESIGNED to to everything. If you really want to, you can create a complete GUI app with just assembly language. But it would be infinitely easier to use a higher-level language like Python, Objective C, Java, etc. FORTRAN was designed for mathematically intense code, while Perl was designed for extraction and reporting; you wouldn't want to write (for example) engineering simulation code in Perl, or Slashcode in FORTRAN.
-Ster
Re:Yeah, good, but ... (Score:2, Interesting)
Re:Who cares? (Score:2, Interesting)
If you do prototyping in python and Cocoa, you can be sure that won't happen.
Re:Who cares? (Score:3, Insightful)
>>Combine the following:
>>Unpopular language: phython
>>Unpopular API: Cocoa
>>Result: a going-nowhere application
Then add some selfish unprofessionalism:
>Actually, you can use that as an advantage. Often
>times employers will ask you to write a "prototype" and
>then when it's done, they fire you and hire some
>monkeys to do upgrades.
>If you do prototyping in python and Cocoa, you can be
>sure that won't happen.
And you get the most godawful excuse to use two of the best new technologies on the planet. Yikes, what a stinker rationale that is. I hate the whole job security attitude. It has loused more promising projects than I care to think about, and has killed many a promising engineers career with apathy and defensive posturing. Once you start thinking in terms of job security, kiss your career and your projects successes goodbye.
What ever happened to using technologies which work well or have the advantage of rapid prototyping? Python and Cocoa both have reputations for being high leverage and powerful without forgoing speed when needed. Isn't that good enough to warrant their use?
Please! Keep job security arguments away from language choice and design decisions.
It is obvious what must be done now. (Score:2)
Clarification (Score:5, Informative)
This is really only of interest to Python programmers that want to leverage Cocoa or ObjC [including Cocoa] programmers that want to leverage the power of Python.
It is not intended to be used as a cross platform solution.
In context, it happens to be extremely powerful. The ability to subclass and extend ObjC classes with Python means that one can build Cocoa applications that can have their classes reloaded and redefined on the fly. I.e. it can greatly reduce the "run-compile" part of the "run-compile-edit" loop that developers tend to be stuck in.
Furthermore, having access to the power of Python from Cocoa greatly reduces the # of lines of code necessary to perform certain tasks. The Python libraries provide great, easy to use, HTTP client/server solutions, excellent XML-RPC support and a slew of other features that are damned handy to have around.
The real value of the PyObjC module-- and credit largely goes to Ronald for this-- is the transparency with which one can interact between languages. This isn't just a messaging solution (like CamelBones). PyObjC provides the developer with the ability to subclass ObjC classes from Python and-- if one really wanted to go there-- subclass Python subclasses of ObjC classes in ObjC.
As well, PyObjC tends to be a bit more straightforward in terms of integration than AppleScript Studio.
Think of it this way: PyObjC allows the developer to quickly and easily prototype applications in a scripting language [Python] while not sacrificing any of the awesome power of Cocoa [and awesome it is!].
Re:Clarification (Score:2)
Correct me if I'm wrong, but doesn't Objective-C allow this as well? Or is it similar, but not quite the same?
It goes with out saying that it is very very cool to have the ability to take existing Python code and make it work with a Cocoa GUI.
Re:Clarification (Score:5, Informative)
The key difference is that doing so in Python doesn't require recompilation and relinking the app (it currently requires relaunching the app, but that is an artificial barrier).
The key advantage is that one can often implement functionality in Python much more rapidly than pure ObjC simply because of the reduction in number of lines of code and the greater degree of abstraction offered by Python.
Even with a pure ObjC Cocoa app, PyObjC can be mixed in to provide a level of scriptability that isn't available in other solutions. Specifically, because Python provides a completely transparent interface between ObjC and Python, an entire application becomes scriptable simply by including PyObjC.
Re:Clarification (Score:2)
See, I thought you could even add Objective-C classes while the program was running, as it's totally dynamic.
As for the productivity gains python creates, I think that's a pretty well known advantage. woohoo python!
Re:Clarification (Score:4, Interesting)
Oh -- certainly -- you can always load a bundle. However, redefining existing classes has always been somewhat limited because of the way ObjC is implemented. Not a criticism of the language-- just the nature of its implementation.
With the Python stuff, it is much easier to effectively redefine everything about a class. This isn't 100% considered within the current implementation, but the potential is there.
Re:Clarification (Score:2)
Re:Clarification (Score:3, Informative)
The bridge was originally written to support the GNUStep runtime. However, support for GNUStep fell out of the current version because none of the active developers are using GNUStep regularly.
The bridge is modular in nature -- there are Foundation and AppKit modules that sit on top of the objc chunk.
It would be a matter of making the objc module portable, then converting AppKit and Foundation to do a similar kind of cross platform support as, say, the os.path module in Python.
RubyCocoa (Score:2, Informative)
great news! (Score:5, Interesting)
People may ask "what's the point?" Well, for starters, Python is absolutely fantastic for building things quickly, especially for complex object or data structures that would take much more time to implement in Objective-C or Java.
On top of this, Python is much better suited for Cocoa than Java! Apple implemented the Java-Cocoa bridge mostly for the sake of having Java be a "supported language." But, since Java is inflexible and strongly typed, it doesn't really fit into the Objective-C model that Cocoa relies on. Python on the other hand is perfectly suited for Cocoa. Python is weakly typed and can handle the dynamic runtime of Cocoa a lot better than a language like Java.
In addition to this, Python's runtime is much more compact than Javas, and manages to load much more quickly. Just fire up Terminal.app and type "python"
I am very excited about the potential of this Python/Cocoa implementation! In the first hour or so since I installed this, I was able to take an existing Python backend and add a quick Cocoa frontend, using nothing but the standard OS X Development Tools.
Kudos to the great people who developed this!
Re:great news! (Score:1)
What about mixing with 3rd party ObjC classes?
I've had no interest in Python until now.
Maybe a TOM bridge is next. I could almost giggle.
Re:great news! (Score:4, Informative)
There is no syntax highlighting for Python in project builder just yet, but I am sure that some creative person can make that happen soon enough. Apple might even implement it if they like the idea of a Python/Cocoa integration.
Can you mix with 3rd Party ObjC classes? I am pretty sure that you can, since this is a Python/Obj-C bridge. I haven't tried it myself, but I am pretty sure that its possible.
The best thing is actually interfacing your Objective-C objects with native Python objects. Create a complex Python data structure, full of lists, objects, tuples, and dictionaries, and then you can use it as the model (MVC) for your application in Cocoa!
You've had no interest in Python? Well, head over to http://www.python.org, and click on the tutorial. Its a great little language, its shipped by default with OS X 10.2, and its trivially easy to learn.