[Pythonmac-SIG] Which version to use??

[Joe Hughes]

I have some questions concerning what I'm reading below.  Ronald states that Python 3.1.2 works with PyObjC on OSX 10.6.  Is this with PyObjC 2.2 on the main site or some branch that is still experimental?  If this is experimental do I use RCS/CVS/Subversion to load it onto my Mac and compile it?  It has been many years since I last used an experimental branch and I forgot how to get it, but I also like using Python 3 on my Mac and have wanted to try PyObjC.

Thanks,
Joe

On May 26, 2010, at 1:54 AM, Ronald Oussoren wrote:

> 
> On 25 May, 2010, at 23:15, Rodney Somerstein wrote:
> 
>> At 10:08 PM +0200 5/25/10, Ronald Oussoren wrote:
>>> Python 3.1.2 works fine on OSX. There is an issue with building extensions on OSX 10.6, but that will be fixed in 3.1.3.
>>> 
>>> PyObjC in the repository works with python 3 and I'm working towards a release. I haven't looked into py2app yet. With some luck it will work without major changes.
>> 
>> Good to hear. Thanks for the hard work on PyObjC. Do you have specific plans to look into py2app for Python 3?
> 
> I will look into py2app after the next release of PyObjC, which will happen before python 2.7rc2 is released.
> 
>> 
>>>> The Mac Python community seems pretty small. Given that Python seems to position itself as a major programming and scripting language, it seems rather strange that there is so little effort placed into providing first class support for the second most popular computing platform. I know that various individuals on this list put a tremendous amount of work into porting and supporting various parts of Python on the Mac platform. But what is the overall state of Python here? Especially in regards to Python 3, which seems to definitely be the future of the language.
>>> 
>>> Porting to py3k is an issue throughout the python community, mostly because cleanly porting non-trivial projects takes time. What hasn't helped is that a lot of project depend on setuptools and that didn't supported until pretty recently (and that only through the 'distribute' fork).
>>> 
>>> As far as PyObjC is concerned port to py3k was a lot of work due to C-API changes and because PyObjC tries to provide seemless integration between Python and Cocoa, which means it is pretty sensitive to the large changes between python 2.x and 3.x.
>>> 
>> 
>> It's great to see dedicated people such as yourself continuing this kind of work. Hopefully things will start to fall into place for Python 3.x. I see questions on comp.lang.python and elsewhere from people wanting to use Python 3.x as their main development language. I think many people, such as myself, are reluctant to jump into Python right now. My perception is that 2.x has a limited life span. It seems not to be the best choice to jump into that right now when the 3.x branch of the language itself is where most work seems to be going on. However, as you noted, many packages aren't trivial to port and that seems to be going very slowly.
> 
> 2.x has a limited life span indeed, but that's still a long time in Internet time: 2.7 will be maintained at least 2 years and longer when there is reason to do so.   The current consensus is that there will be no 2.8 though, which means there will be no new features in 2.x after the release of 2.7 (later this summer).
> 
> IMHO there is a chicken-and-egg problem: there aren't a lot of python 3 users and hence there is little uptake in porting libraries to python 3. However, the reason there aren't a lot of python 3 users is that a lot of libraries aren't available yet.
> 
>> 
>> Are you planning on focusing on 3.x from this point forward with only maintenance on the 2.x version of PyObjC?
> 
> No. The C code for PyObjC contains lots of conditional code to be able to compile with both branches, while the Python code translates cleanly with 2to3. 
> 
> Having two development branches 
>> 
>> How far away is Python 3 from being the main branch of the language? Are we talking another year? 2? 5?
> 
> Most new work in CPython is done in python 3, and when 2.7 is released all new features will only be 3.x.
> 
>> 
>>>> I have looked at moving into Python several times over the years, but it always seems to be a second class language when it comes to producing programs to run on the Mac. At least outside of various command line tools. Is Python moving toward parity with the Windows and Unix world on the Macintosh?
>>> 
>>> What do you mean?  Python on OSX is support as well as it is on Linux and Windows.
>> 
>> I'm not trying to denigrate the hard work that you and others put into keeping Python functioning well on the Mac. In part, due to the fact that packaging seems to be trickier for people to figure out with py2app than with py2exe I have gotten that impression. Maybe most people are using py2app with very little trouble and I'm only seeing the problems and requests for help that get reported here.
> 
> Py2app works at least as well as py2exe.  The requests you see here are for the harder problems. IIRC two issues crop up reasonably often: (1) support for using py2app with a 64-bit build of python and (2) using py2app with libraries like Qt4 where the automatic detection of dependencies doesn't work.
> 
> Support for 64-bit builds is relatively new, and full support requires some additional changes to py2app. As I'm the only developer on py2app and do all work in my free time it may take a while until I get around to publishing those changes.
> 
> The second class of problem could be fixed by recipes in py2app, and already is for a number of libraries. This is something where py2app is actually easier to use than py2exe, it is an explicit goal of py2app to automate as much as possible and avoid the need for pages like this <http://www.py2exe.org/index.cgi/WorkingWithVariousPackagesAndModules>.
> 
>> 
>> It sounds like for pure Mac development, that a bit of testing and hopefully minor tweaking will be enough to get py2app running well. Once that is done, Python 3 may actually work as a great development language for Mac applications. The only thing really missing once that is done is a port of a good cross-platform UI library, such as wxWidgets, so that cross-platform apps can be developed easily.
> 
> The python bindings for wxWidgets work fine with python 2, I don't know what their plans for python 3 are. PyQt already supports python 3 (at least on Windows, I haven't looked at their Mac port yet).
> 
> To be honest, I'm far from impressed by the quality of the wxWidgets port to the Mac. I've run into numerous issues in the past where API calls worked just fine on Windows but failed to work on OSX. That isn't very helpfull when you want to do the groundwork of a Windows app using wxWidgets on OSX and do as little as possible on an actual windows machine.
> 
>> 
>> I also think that another part of the issue is simply that there are many more Windows developers than Mac developers. This means simply that more packages get released for Windows earlier than on the Mac. Similarly there may be more UI libraries and such under Windows because more people write them.
> 
> It should be easier to develop packages with C extensions on OSX than on Windows, on Windows you basicly have to buy a compiler (although free versions for the MS tools and the MingW port of GCC may also work for some versions of those tools and some versions of Python).
> 
>> 
>> For Unix/Linux, I suspect that a larger percentage of the users are actually developers, based on what I've seen in the past. That would tend to lead to more people capable of fixing code and contributing to ports themselves on those platforms.
>> 
>> Maybe what I have to resign myself to is that if I want to develop in Python 3 (or any Python for that matter) for desktop applications, I need to be willing to live with any limitations. This is because I don't have the skill to code around those limitations in C. Alternatively I could develop my C and C++ skills as well as Python skills all at the same time so that I can port needed packages. That doesn't seem very realistic. This may just be a matter of the open source nature of Python.
> 
> Why not use PyObjC to build the GUI? This will allow you to write fully native applications that can make use of a significant portion of the OSX platform.
> 
> Ronald
>> 
>> -Rodney
>> 
>> 
>> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG at python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG