至于 Objective-C：The Hillegass book 是最受欢迎的，但我没有不要使用它。 （我浏览了一下，看起来不错。）我阅读了 Apple 的文档语言，然后直接开始编写小型 Cocoa 应用程序。我阅读了一些指南，结果好坏参半。有货币转换器教程，但没有对我有帮助，并且不能完全反映现代的 Cocoa 应用程序。 （现代应用程序仍然使用出口和操作，但也使用绑定，而现实的货币转换器几乎完全是几个绑定。）
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:
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:
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.)
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.
如果您要为 Mac 编写应用程序，请不要尝试以避免学习 Objective-C。 PyObjC 和其他语言绑定的目的是让您在应用程序中重用现有的库，而不是让您避免学习本机工具。
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.
二等公民似乎有点强。如果您需要的话，Objective-C API 也可以从 Python 获得，这主要是在您想要制作 Cocoa 应用程序时。但无论如何，它们都仅限于 OS X。就我个人而言，我对构建非跨平台的应用程序不感兴趣，但这就是我。这也意味着我还没有真正做过这件事，所以我不知道它有多棘手，但是不久前Python杂志上有一篇文章，看起来并没有那么可怕。
Python 的主要缺点是执行时间，这主要是因为它是一种动态语言。这可以通过 Cython 和 C 扩展等来解决，但随后你会得到 Python + ObjectiveC API + Cython 的混合，这可能会令人望而生畏。
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.
由于您可以访问所有库和事件，因此您在 Objective C 中可以执行的所有操作都将在 Python 中实现。当然，您使用的仅限 OS X 的调用和函数越多，移植到另一个平台就越困难，但这不是重点。通常图形编程和使用设备驱动程序在某种程度上是一个限制因素 - 但在这两种情况下，我都找到了良好支持和社区库的证据（搜索 Python 和 Quartz、Lightblue、libhid、PyUSB 等一些示例）。
对我来说，决定性因素是：所需的工具和 IDE 支持的级别是什么。 Apple 提供了一些用于构建新软件的出色软件，但像 Pydev 这样的软件也为您提供了编写 Python 代码的好地方！ http://pydev.org/
所以尝试一下，我相信你不会后悔的，并且会有一个支持社区来提供帮助和灵感。
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.
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.
作为一个额外的选项，考虑一下 wxPython 可以在 Mac 以及 Linux 和 Windows 上生成一些非常好的应用程序。在大多数情况下，您可以获得本机外观，但保持可移植性，而很少或根本不关注特定于平台的问题。
换句话说，PyObjC + Python 并不是使用 Python 进行 Mac 开发的唯一方法。
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.
除非您想做一些针对 MAC 平台极其特定的事情，否则用 Objective C 编码或使用 PyObjC 是一个非常糟糕的主意。
原因很明显，一旦你走上 objc 路线，你就和其他平台说再见了。就这么简单。
Apple 不希望您为其他平台编写代码，就像 Microsoft 不希望您为其他平台编写代码一样。这就是为什么越来越多的开发人员转向Python、Java、Ruby等开源语言。因为你不关心什么Apple和Microsot，你只关心一个最有用、最容易开发的应用程序。让你的应用程序仅适用于 MAC 会降低它的用处，并且显然在 Objective C 中开发会更加困难。
Python 有足够多的库来满足您的需要，有数百个，可随时用于 mac 平台。例如，我在 pygame 中开发一个新应用程序，不，它不是游戏，如果我在 ObjC 或 PyObj 中做了同样的事情，我将不得不重写 Windows 和 Linux 的代码。尽管我的主要平台是 macos，但使用 pygame 我的代码在 Windows 和 Linux 中的工作原理完全相同。
但说实话，如果我的应用程序与 python 库陷入死胡同（一种非常不可能的情况），我宁愿用 Cython 包装现有的跨平台 C/C++ 库，也不愿走目标 c pyobjc 路线并破坏交叉我的应用程序的平台能力。我最不想使用的东西是平台特定的东西。
现在，如果您根本不关心其他平台，那么我想 Objective C 可能是一个有效的选择。它确实看起来很难看，但我听说你使用它越多它就会变得越好，并且有很多人比 C/C++ 更喜欢它。
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.
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++.
发布评论
评论（8）
是的。
一方面，正如您所注意到的，所有文档都是为 Objective-C 编写的，这是一种非常不同的语言。
区别之一是方法名称。在 Objective-C 中，当您向对象（Python 会说“调用某个方法”）发送消息时，方法名称（选择器）和参数是混合的：
这在 Python 中是不可能的。 Python 的关键字参数不计为方法名称的一部分，因此如果您这样做：
您将得到一个异常，因为 QTMovie 类没有名为
movieWithURL的方法； Objective-C 示例中的消息使用选择器movieWithURL:error:。movieWithURL:和movieWithURL将是另外两个选择器。他们无法改变这一点，因为 Python 的关键字参数没有排序。假设您有一个假设的三参数方法：
现在，这会调用
foo:bar:baz:，对吧？没那么快。 Foo 还可能有一个名为 foo:baz:bar: 的方法。因为 Python 的关键字参数没有排序，所以您实际上可能正在调用该方法。同样，如果您尝试调用
foo:baz:bar:，实际上最终可能会调用foo:bar:baz:。实际上，这种情况不太可能发生，但如果发生，您将无法可靠地调用任一方法。因此，在 PyObjC 中，您需要像这样调用该方法：
您可能想知道 ???. C 不允许多个返回值，因此，在 Objective-C 中，
error:参数采用指向指针变量的指针，并且该方法将在该变量中存储一个对象（这称为 return -通过参考）。 Python 没有指针，因此桥处理像这样的参数的方式是传递 None，并且该方法将（似乎）返回一个元组。因此，正确的示例是：您可以看到，即使是一个简单的示例，也与 Objective-C 中文档可能向您展示的内容有多么不同。
还有其他问题，例如 GIL。 Cocoa 应用程序只会变得更加并发，并且您会想要参与其中，尤其是像 NSOperation 这样诱人的类。 GIL 是一个严重的负担，尤其是在多核机器上。我自己是作为一个 Python 爱好者这样说的（当我不是为 Cocoa 编写代码时）。正如大卫·比兹利（David Beazley）在该视频中所展示的那样，这是一个冷酷无情的事实；无可否认。
因此，如果我要在应用程序中放弃 Objective-C，我会选择 MacRuby。与 PyObjC 和 RubyCocoa 不同，发送给 Cocoa 对象的消息不会跨越语言桥梁；它是 Cocoa 中从头开始的 Ruby 实现，具有语言扩展以更好地支持在其中编写 Cocoa 代码。
但这对你来说太遥远了。你才刚刚开始。从 Objective-C 开始。最好通过保持相同的语言来避免您正在使用的语言和文档所针对的语言之间出现所有阻抗不匹配的情况。
另外，如果不了解 Objective-C 的工作原理，您会发现一些错误（例如发送给已故对象的消息）更难诊断。作为一名新的 Cocoa 程序员，无论您使用哪种语言编写代码，您都会编写这些错误。
因此，学习 C，然后学习 Objective-C。掌握两者的实用知识不会超过几周的时间，最终，您将为其他一切做好更好的准备。
我就不讲我是怎么学C的了；我只想说我不推荐我这样做的方式。我听说这本书很好，但我从未拥有过，也没有读它。我确实有
至于 Objective-C：The Hillegass book 是最受欢迎的，但我没有不要使用它。 （我浏览了一下，看起来不错。）我阅读了 Apple 的文档语言，然后直接开始编写小型 Cocoa 应用程序。我阅读了一些指南，结果好坏参半。有货币转换器教程，但没有对我有帮助，并且不能完全反映现代的 Cocoa 应用程序。 （现代应用程序仍然使用出口和操作，但也使用绑定，而现实的货币转换器几乎完全是几个绑定。）
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:
This isn't possible in Python. Python's keyword arguments don't count as part of the method name, so if you did this:
you would get an exception, because the QTMovie class has no method named
movieWithURL; the message in the Objective-C example uses the selectormovieWithURL:error:.movieWithURL:andmovieWithURLwould 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:
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 callfoo:baz:bar:, you may actually end up callingfoo: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:
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: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.)
这确实说明了一切：
此问题的答案中的评论。 这个问题也很有趣。
This really says it all:
a comment in an answer to this question. This question is also interesting.
如果您要为 Mac 编写应用程序，请不要尝试以避免学习 Objective-C。 PyObjC 和其他语言绑定的目的是让您在应用程序中重用现有的库，而不是让您避免学习本机工具。
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.
二等公民似乎有点强。如果您需要的话，Objective-C API 也可以从 Python 获得，这主要是在您想要制作 Cocoa 应用程序时。但无论如何，它们都仅限于 OS X。就我个人而言，我对构建非跨平台的应用程序不感兴趣，但这就是我。这也意味着我还没有真正做过这件事，所以我不知道它有多棘手，但是不久前Python杂志上有一篇文章，看起来并没有那么可怕。
Python 的主要缺点是执行时间，这主要是因为它是一种动态语言。这可以通过 Cython 和 C 扩展等来解决，但随后你会得到 Python + ObjectiveC API + Cython 的混合，这可能会令人望而生畏。
因此，这在很大程度上取决于您要制作什么类型的应用程序。一些独特的 OSX 式的东西在其他地方没有意义？ ObjectiveC 可能就是门票。跨平台服务器，Python 太棒了！还有别的事吗？那要看情况了。
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.
这是我自己一直想知道的事情，虽然我希望有人有更多的经验，但据我所知，你不会受到 Python 本身的严重限制。与 Java 和 GCC 一样，Python 是编写本机跨平台应用程序的绝佳方法。一旦掌握了它的窍门，您应该能够将 Objective C 中的示例代码映射到您的 Python 代码。
由于您可以访问所有库和事件，因此您在 Objective C 中可以执行的所有操作都将在 Python 中实现。当然，您使用的仅限 OS X 的调用和函数越多，移植到另一个平台就越困难，但这不是重点。通常图形编程和使用设备驱动程序在某种程度上是一个限制因素 - 但在这两种情况下，我都找到了良好支持和社区库的证据（搜索 Python 和 Quartz、Lightblue、libhid、PyUSB 等一些示例）。
对我来说，决定性因素是：所需的工具和 IDE 支持的级别是什么。 Apple 提供了一些用于构建新软件的出色软件，但像 Pydev 这样的软件也为您提供了编写 Python 代码的好地方！ http://pydev.org/
所以尝试一下，我相信你不会后悔的，并且会有一个支持社区来提供帮助和灵感。
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.
您将需要 Objective-C：所有教程、文档、示例代码和所有内容都是用 Objective-C 编写的。此外，还有更多的人能够为您提供帮助。
所以先学ObjC。如果在您的第二个或第三个项目中，或者一年后，您开始一个需要 Python 模块的项目（例如 Twisted 或 SQLAlchemy）。但是像应用程序的基础这样的严重需求需要额外的提升你的应用程序让一切都值得），然后你可以编写一个 PyObjC 应用程序，并获得该语言的许多速度优势，并具有 Cocoa 背景。
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.
作为一个额外的选项，考虑一下 wxPython 可以在 Mac 以及 Linux 和 Windows 上生成一些非常好的应用程序。在大多数情况下，您可以获得本机外观，但保持可移植性，而很少或根本不关注特定于平台的问题。
换句话说，PyObjC + Python 并不是使用 Python 进行 Mac 开发的唯一方法。
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.
不，你不需要了解 Objective C，你不需要使用 PyObjC，你也不会成为二等公民。
除非您想做一些针对 MAC 平台极其特定的事情，否则用 Objective C 编码或使用 PyObjC 是一个非常糟糕的主意。
原因很明显，一旦你走上 objc 路线，你就和其他平台说再见了。就这么简单。
Apple 不希望您为其他平台编写代码，就像 Microsoft 不希望您为其他平台编写代码一样。这就是为什么越来越多的开发人员转向Python、Java、Ruby等开源语言。因为你不关心什么Apple和Microsot，你只关心一个最有用、最容易开发的应用程序。让你的应用程序仅适用于 MAC 会降低它的用处，并且显然在 Objective C 中开发会更加困难。
Python 有足够多的库来满足您的需要，有数百个，可随时用于 mac 平台。例如，我在 pygame 中开发一个新应用程序，不，它不是游戏，如果我在 ObjC 或 PyObj 中做了同样的事情，我将不得不重写 Windows 和 Linux 的代码。尽管我的主要平台是 macos，但使用 pygame 我的代码在 Windows 和 Linux 中的工作原理完全相同。
这就是大多数Python库的吸引力，它们是跨平台的。 WxPython 是另一个例子，有人提到“它看起来并不完全是原生的”，你是否希望这阻止你让你的应用程序可用于 Windows 和 Linux。为什么要把自己限制在MAC平台上呢？您认为普通用户会关心您的应用程序的外观吗？即使 Macos 应用程序看起来也不是原生的，其中许多都引入了自己的“养眼”GUI。并不是说你不能让 WxPython 看起来 100% 原生，你的编码方式始终很重要。
当你打算为 Iphone OS 进行开发时，Objc 是有意义的，因为 Apple 认为排除 python（不仅是 python）是个好主意，即使他们被迫包含 javascript（否则网络冲浪将成为 iphoneos 上的噩梦）。 Pyjamas，也可以使 python 可用于 iphone 操作系统（无需黑客攻击或越狱手机），但由于它将 python 代码转换为 javascript，因此具有明显的局限性，但在 Apple 决定将 python 排除在 iphone 操作系统之外之前，它仍然是一个有效的解决方案真是个坏主意。
链接文本
不过，学习 Objective C 并没有什么坏处。您始终可以通过 pyobjc 使用本机库。
但说实话，如果我的应用程序与 python 库陷入死胡同（一种非常不可能的情况），我宁愿用 Cython 包装现有的跨平台 C/C++ 库，也不愿走目标 c pyobjc 路线并破坏交叉我的应用程序的平台能力。我最不想使用的东西是平台特定的东西。
现在，如果您根本不关心其他平台，那么我想 Objective C 可能是一个有效的选择。它确实看起来很难看，但我听说你使用它越多它就会变得越好，并且有很多人比 C/C++ 更喜欢它。
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++.