From ronaldoussoren at mac.com  Sun Aug  1 08:55:29 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 01 Aug 2010 08:55:29 +0200
Subject: [Pythonmac-SIG] py2app error
In-Reply-To: <FEC76414-302C-441C-85A5-4B02A74FCDB5@gmail.com>
References: <4DD5585D-1E8F-4D26-955A-43BCF01F50FF@gmail.com>
	<A4F1AE89-6EAB-4652-8CFD-BAE7AAB9D278@mac.com>
	<53F2A68A-9415-474D-88EB-78A2F3E986A2@mac.com>
	<32CA16F6-27E7-45A8-9808-C58688D96A85@gmail.com>
	<F3589161-524F-42A5-B2B7-5DA9892AEEC6@mac.com>
	<FEC76414-302C-441C-85A5-4B02A74FCDB5@gmail.com>
Message-ID: <D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>


On 31 Jul, 2010, at 23:02, Nathan Lemoine wrote:

> Running the testing application in the command line did confirm that the pyglet module isn't being found:
> 
>  File "/Users/Nate/dist/tester.app/Contents/Resources/__boot__.py", line 160, in _run
>    execfile(path, globals(), globals())
>  File "/Users/Nate/Desktop/tester.py", line 1, in <module>
>    import pyglet
> ImportError: No module named pyglet
> 
> Is there a way to manually add the path for pyglet to py2app's search or in the setup.py file to force the module to be loaded?

This is very odd. Which version of Python do you use? And likewise for pyglet?

I've installed pyglet for python 2.6 using the 1.1.4 binary installer on their site, and used "easy_install-2.7 pyglet" to install the python parts for python 2.7. Both result in a working application bundle.

There is misfeature in pyglet that makes this bundle not-quite-standalone though,  the pyglet sources explicitly load /usr/local/lib/libavbin.dylib using ctypes.  I could create a py2app recipe that copies libavbin.dylib into the application bundle, but that will probably not be used without patching the pyglet sources.

I've attached the scripts I used to test.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: setup.py
Type: text/x-python-script
Size: 66 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100801/230a6946/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: runner.py
Type: text/x-python-script
Size: 555 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100801/230a6946/attachment-0004.bin>
-------------- next part --------------
> 
> On Jul 30, 2010, at 1:54 AM, Ronald Oussoren wrote:
> 
>> 
>> On 30 Jul, 2010, at 2:59, Nathan Lemoine wrote:
>> 
>>> I installed the 0.5.2 update, and I've tried making just a very simple pyglet app to play a movie file so that you all could try it if you want on your python distributions:
>>> 
>>> import pyglet
>>> 
>>> vidPath="video.avi" ##put the path to a video file here
>>> window = pyglet.window.Window()
>>> source = pyglet.media.StreamingSource()
>>> MediaLoad = pyglet.media.load(vidPath)
>>> player = pyglet.media.Player()
>>> player.queue(MediaLoad)
>>> player.play()
>>> 
>>> @window.event
>>> def on_draw():
>>> 	player.get_texture().blit(0,0)
>>> 
>>> pyglet.app.run()
>> 
>> Thanks for the demo, that will definitly help in reproducing and fixing the problem.
>> 
>>> 
>>> Executing python setup.py py2app still gives me the same error:
>>> 
>>> Traceback (most recent call last):
>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/py2app/build_app.py", line 604, in _run
>>>  self.run_normal()
>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/py2app/build_app.py", line 675, in run_normal
>>>  self.create_binaries(py_files, pkgdirs, extensions, loader_files)
>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/py2app/build_app.py", line 739, in create_binaries
>>>  dry_run=self.dry_run)
>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/py2app/util.py", line 376, in byte_compile
>>>  if force or newer(mod.filename, cfile):
>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/py2app/util.py", line 172, in newer
>>>  msource = get_mtime(source)
>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/py2app/util.py", line 164, in get_mtime
>>>  info = zf.getinfo(rest)
>>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/zipfile.py", line 462, in getinfo
>>>  return self.NameToInfo[name]
>>> KeyError: 'pyglet/__init__.pyc'
>>>> /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/zipfile.py(462)getinfo()
>>> -> return self.NameToInfo[name]
>>> (Pdb)
>>> 
>>> I ran it in alias mode as well and it bundled 'tester.app' successfully. When I attempted to run the bundle, I just got a dialog box that said 'tester Error' and brought me to the MacPython website. I'm not sure how to find out what the issue is with the aliased bundle.
>> 
>> You can run the app from the command-line:  test.app/Contents/MacOS/tester
>> 
>> When you do that you'll get error messages in your terminal window, and those should explain what's going on.  I expect that pyglet cannot be found.
>> 
>>> 
>>> Thanks for the help so far! I really appreciate it. I don't think I could figure this out on my own
>> 
>> I haven't had time to look into this issue specifically, I'll do so in the near future.
>> 
>> Ronald
>> 
>> 
>>> 
>>> 
>>> 
>>> On Jul 29, 2010, at 2:34 AM, Ronald Oussoren wrote:
>>> 
>>>> 
>>>> On 29 Jul, 2010, at 8:09, Ronald Oussoren wrote:
>>>> 
>>>>> 
>>>>> On 28 Jul, 2010, at 18:38, Nathan Lemoine wrote:
>>>>> 
>>>>>> 
>>>>>> Traceback (most recent call last):
>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/build_app.py", line 602, in _run
>>>>>> self.run_alias()
>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/build_app.py", line 548, in run_alias
>>>>>> dst = self.build_alias_executable(target, target.script)
>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/build_app.py", line 1145, in build_alias_executable
>>>>>> appdir, resdir, plist = self.create_bundle(target, script)
>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/build_app.py", line 1131, in create_bundle
>>>>>> use_runtime_preference=use_runtime_preference
>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/build_app.py", line 1120, in create_appbundle
>>>>>> extension=self.extension,
>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/create_appbundle.py", line 34, in create_appbundle
>>>>>> copy(srcmain, destmain)
>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/util.py", line 233, in mergecopy
>>>>>> return macholib.util.mergecopy(src, dest)
>>>>>> File "build/bdist.macosx-10.5-i386/egg/macholib/util.py", line 111, in mergecopy
>>>>>> copy2(src, dest)
>>>>>> File "build/bdist.macosx-10.5-i386/egg/macholib/util.py", line 43, in copy2
>>>>>> shutil.copy2(fsencoding(src), fsencoding(dst))
>>>>>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/shutil.py", line 91, in copy2
>>>>>> copyfile(src, dst)
>>>>>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/shutil.py", line 46, in copyfile
>>>>>> fsrc = open(src, 'rb')
>>>>>> IOError: [Errno 2] No such file or directory: '/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/apptemplate/prebuilt/main-i386'
>>>>>>> /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/shutil.py(53)copyfile()
>>>>>> -> fsrc.close()
>>>>>> 
>>>>>> I went into the Python Framework folder and the only prebuilt executeable in there is 32bit one, there isn't a main-i386 file. Am I missing a file?
>>>>> 
>>>>> You aren't missing a file, py2app doesn't have a main-i386 file.  As a quick workaround you can copy /Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/apptemplate/prebuilt/main-fat  to /Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/py2app/apptemplate/prebuilt/main-i386.
>>>>> 
>>>>> I will tweak py2app to better handle this, that will be in the next release (0.5.2, hopefully later this week).
>>>> 
>>>> I've upload py2app 0.5.2. With this version I can build a pyobjc application using python 2.5 (without the IOError exception), the pyglet error is not yet fixed.
>>>> 
>>>> Ronald
>>>> 
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100801/230a6946/attachment-0005.bin>

From ronaldoussoren at mac.com  Sun Aug  1 13:59:48 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 01 Aug 2010 13:59:48 +0200
Subject: [Pythonmac-SIG] [Pyobjc-dev] Py2app too complex?
In-Reply-To: <AANLkTim_CAACrBa5jp6b9hBZFaXrc6tytf5Uc9UoPKU5@mail.gmail.com>
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>
	<AANLkTinhiH-=SO9PRhGS=Szwbg2zs=S0OQBwtwc-u4Th@mail.gmail.com>
	<4C5377B8.2080105@canterbury.ac.nz>
	<6C56C7A5-891E-4A32-B9C2-27A459D03969@mac.com>
	<AANLkTim_CAACrBa5jp6b9hBZFaXrc6tytf5Uc9UoPKU5@mail.gmail.com>
Message-ID: <8FB5CA02-BEDC-4A68-86D4-F4B05C2963E3@mac.com>


On 31 Jul, 2010, at 10:56, Virgil Dupras wrote:

> On Sat, Jul 31, 2010 at 10:26 AM, Ronald Oussoren
> <ronaldoussoren at mac.com> wrote:
>> 
>> On 31 Jul, 2010, at 3:09, Greg Ewing wrote:
>> 
>>> Virgil Dupras wrote:
>>>> Is it possible that py2app is a little too complex for what
>>>> it does?
>>> 
>>> I think a lot of the complexity of py2app and py2exe come
>>> from trying to automatically figure out what modules and
>>> libraries need to be included.
>> 
>> I object to calling py2app complex, the code base is fairly easy to understand.   Have you even looked at the code base?
>> 
>>> 
>>> I've been thinking for a while about creating something
>>> simpler that doesn't attempt any automatic module discovery
>>> at all. You would be required to construct a project file
>>> that explicitly lists all the required modules and libraries,
>>> including standard library modules.
>> 
>> That is not simpler, it just shifts the complexity to the user. It is better to shift the complexity away from the user, that way the user does not have to reinvent the weel.
>> 
>> Ronald
>> ------------------------------------------------------------------------------
>> The Palm PDK Hot Apps Program offers developers who use the
>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
>> of $1 Million in cash or HP Products. Visit us here for more details:
>> http://p.sf.net/sfu/dev2dev-palm
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyobjc-dev at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>> 
>> 
> 
> I'm not sure I agree that no dependency finding would be a good thing.
> Importing a stdlib modules often imports tons of other ones you don't
> know about and manually figuring these dependencies out can be really
> tedious. However, I think that using modulegraph instead of the
> built-in modulefinder is a mistake. For one thing, modulegraph doesn't
> support relative imports, yet.

Adding is possible, and will be done. I'm working on that right now to be honest, and that code should be done by the end of the day (including unittests).

I don't agree that using modulefinder would be better. For one, modulefinder will never support setuptools trickery (see the zope.interface discussion on pythonmac-sig), while that can and will be added to modulegraph.

> Yeah, we could work on it, but why
> bother when modulefinder already does it? It's just more maintenance.
> I know modulegraph is supposed to be better, but I would *gladly* list
> my non-stdlib dependencies manually rather than pray that py2app finds
> them correctly. The way I work with py2app now is that whenever a
> dependency isn't found by py2app, I put an explicit import of it in my
> "main py file" in a section documented for being py2app workaround
> imports. It works, but I'm sure there's a more elegant way...

You can add an includes section to your setup.py file (see the includes argument on the command-line).

What would be better is to research why py2app doesn't find modules you use, or at least try to create a small sample that demonstrates the problem   I cannot fix issues if you don't report them.
> 
> I think distutils is supposed to let you list dependencies manually in
> the setup() call, but when I tried it I found it extremely
> non-working, at all. So yes, a reliable way to manually list
> dependencies would be a great thing.

setuptools has install_requires/setup_requires, but py2app does not have support for that yet (although setup_requires should ensure that the eggs your require are installed before py2app gets run).

You can also list includes/excludes in the py2app options dictionary:

	setup(
		options=dict(py2app=dict(
			include=['mymodule'],	
                ))
        )

Ronald

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100801/1eff66ab/attachment.bin>

From ronaldoussoren at mac.com  Sun Aug  1 14:50:39 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 01 Aug 2010 14:50:39 +0200
Subject: [Pythonmac-SIG] [Pyobjc-dev] Py2app too complex?
In-Reply-To: <8FB5CA02-BEDC-4A68-86D4-F4B05C2963E3@mac.com>
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>
	<AANLkTinhiH-=SO9PRhGS=Szwbg2zs=S0OQBwtwc-u4Th@mail.gmail.com>
	<4C5377B8.2080105@canterbury.ac.nz>
	<6C56C7A5-891E-4A32-B9C2-27A459D03969@mac.com>
	<AANLkTim_CAACrBa5jp6b9hBZFaXrc6tytf5Uc9UoPKU5@mail.gmail.com>
	<8FB5CA02-BEDC-4A68-86D4-F4B05C2963E3@mac.com>
Message-ID: <DB21418E-4CFF-4042-BF51-B6CADFD64487@mac.com>


On 1 Aug, 2010, at 13:59, Ronald Oussoren wrote:
>> 
>> I'm not sure I agree that no dependency finding would be a good thing.
>> Importing a stdlib modules often imports tons of other ones you don't
>> know about and manually figuring these dependencies out can be really
>> tedious. However, I think that using modulegraph instead of the
>> built-in modulefinder is a mistake. For one thing, modulegraph doesn't
>> support relative imports, yet.
> 
> Adding is possible, and will be done. I'm working on that right now to be honest, and that code should be done by the end of the day (including unittests).

The version of modulegraph in the repository now supports absolute and relative imports (with unittests)

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100801/5657663f/attachment.bin>

From Chris.Barker at noaa.gov  Sun Aug  1 19:08:14 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Sun, 01 Aug 2010 10:08:14 -0700
Subject: [Pythonmac-SIG] py2app error
In-Reply-To: <D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>
References: <4DD5585D-1E8F-4D26-955A-43BCF01F50FF@gmail.com>
	<A4F1AE89-6EAB-4652-8CFD-BAE7AAB9D278@mac.com>
	<53F2A68A-9415-474D-88EB-78A2F3E986A2@mac.com>
	<32CA16F6-27E7-45A8-9808-C58688D96A85@gmail.com>
	<F3589161-524F-42A5-B2B7-5DA9892AEEC6@mac.com>
	<FEC76414-302C-441C-85A5-4B02A74FCDB5@gmail.com>
	<D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>
Message-ID: <4C55A9FE.7070909@noaa.gov>

Ronald Oussoren wrote:
> the pyglet sources explicitly load /usr/local/lib/libavbin.dylib using ctypes.  I could create a py2app recipe that copies libavbin.dylib into the application bundle, but that will probably not be used without patching the pyglet sources.


This is a problem in general with all ctypes uses. In fact, ctypes 
reminds me a bit of py2app in the sense that it has some built-in 
algorithms for searching for dynamic libs, and that these fail fairly often.

As for py2app, maybe the ctypes recipe could patch ctypes to look in a 
particular place in teh bundle, and then the user could specify which 
libs ctypes used, and py2ap would put them in the bundle.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From Chris.Barker at noaa.gov  Sun Aug  1 19:29:15 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Sun, 01 Aug 2010 10:29:15 -0700
Subject: [Pythonmac-SIG] Py2app too complex?
In-Reply-To: <4C5377B8.2080105@canterbury.ac.nz>
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>
	<AANLkTinhiH-=SO9PRhGS=Szwbg2zs=S0OQBwtwc-u4Th@mail.gmail.com>
	<4C5377B8.2080105@canterbury.ac.nz>
Message-ID: <4C55AEEB.7060203@noaa.gov>

Greg Ewing wrote:
> I've been thinking for a while about creating something
> simpler that doesn't attempt any automatic module discovery
> at all. You would be required to construct a project file
> that explicitly lists all the required modules and libraries,
> including standard library modules.

I've thought for a while that there is way too much re-invention of the 
wheel with the various stand-alone builders. I'd love to see more 
flexibility, and ideally code sharing, by breaking down the process into 
the various parts:

1) the API for specifying what you need built -- py2app and py2exe at 
least share much )but not all) of this, though they are slightly 
incompatible. AFAIK, the rest are all different

2) Figuring out what needs to be included. py2app and bbfreeze both use 
modulegraph, though bb-freeze apparently forked it.

3) Actually building the bundle -- by definition this will be different 
on different platforms, and there are multiple ways of doing it on one 
platform

Anyway, ideally, each of these steps could share a common API, and so 
each bundle builder could mix and match the parts as they saw fit.

Getting everyone to cooperate is a big social, rather then technical 
problem, but py2app at least could be designed to allow each of these 
pieces to be replaceable. (maybe it already is -- I haven't poked into 
the code enough to know)

So, aside from allowing more code sharing, this approach would make it 
easier to plug in different pieces, like Greg's proposed manual 
specification of modules.

As for that proposal -- I agree with other posters that that really 
would be onerous. However, a hybrid would be great -- run some sort of 
automated tool that outputs an easy-to-read-and-edit text file that 
could be edited, and have the bundle builder use that. Then you culd 
e3dit it, write it frm scratch, whatever you like.

If nothing else, it would really help speed to be able to re-build an 
app without having to go through the process of determining what to 
include each time. I often find myself modifying the source a bit, 
knowing for sure that I haven't changed the dependencies, and then 
having to wait for py2app (or py2exe) to do the full analysis again.

Another idea I have for determining what to include is to take the 
opposite tack of source-code analysis -- run-time analysis:

You would run your app (or better yet, a test suite), and the tool would 
do a run-time examination of what's imported (would that be as simple as 
looking in sys.modules?). That way you would capture the dynamic imports 
that the source-code analysis misses. You would miss the conditional 
imports, but if you have a good test suite, you'd catch those too. (and 
if you don't, you'd have identified a hole in your tests). And you would 
miss the conditional imports that you really don't want ( I never want 
Tk just because I'm using PIL, for instance)

If you really wanted a I-don't-care-how-big-it-is-I-just-want-it-to-work 
version, you could use a superset of runt-time and source-code analysis.


I do want to be clear that py2app has been the best bundle builder I've 
used, and I really appreciate Ronald's effort to bring it up to speed again.


-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From ronaldoussoren at mac.com  Sun Aug  1 22:01:31 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 01 Aug 2010 22:01:31 +0200
Subject: [Pythonmac-SIG] py2app error
In-Reply-To: <4C55A9FE.7070909@noaa.gov>
References: <4DD5585D-1E8F-4D26-955A-43BCF01F50FF@gmail.com>
	<A4F1AE89-6EAB-4652-8CFD-BAE7AAB9D278@mac.com>
	<53F2A68A-9415-474D-88EB-78A2F3E986A2@mac.com>
	<32CA16F6-27E7-45A8-9808-C58688D96A85@gmail.com>
	<F3589161-524F-42A5-B2B7-5DA9892AEEC6@mac.com>
	<FEC76414-302C-441C-85A5-4B02A74FCDB5@gmail.com>
	<D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>
	<4C55A9FE.7070909@noaa.gov>
Message-ID: <DD38B830-00D1-48D3-8975-4F5A802CB103@mac.com>


On 1 Aug, 2010, at 19:08, Christopher Barker wrote:

> Ronald Oussoren wrote:
>> the pyglet sources explicitly load /usr/local/lib/libavbin.dylib using ctypes.  I could create a py2app recipe that copies libavbin.dylib into the application bundle, but that will probably not be used without patching the pyglet sources.
> 
> 
> This is a problem in general with all ctypes uses. In fact, ctypes reminds me a bit of py2app in the sense that it has some built-in algorithms for searching for dynamic libs, and that these fail fairly often.

Please file bugs for that, I'm pretty sure that ctypes is supposed to implement the same algoritms as the platform dynamic linker.

W.r.t. py2app: I consider cases where py2app doesn't find modules or shared libraries bugs and should be fixed, either by making the core smarter or by adding recipes.   Please post reports about issues, especially when you can reproduce them in smallish examples (or at least examples that you can share with the outside world).

> 
> As for py2app, maybe the ctypes recipe could patch ctypes to look in a particular place in teh bundle, and then the user could specify which libs ctypes used, and py2ap would put them in the bundle.

Yes, but that will require some additional trickery to ensure that ctypes looks in this special location before looking at the full name specified by the caller.

Actually finding which libraries are loaded using ctypes will sadly enough be impossible in general, although recipes could be used for the popular libaries.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100801/bf194ac4/attachment.bin>

From lemoine.nathan at gmail.com  Mon Aug  2 02:58:46 2010
From: lemoine.nathan at gmail.com (Nathan Lemoine)
Date: Sun, 1 Aug 2010 20:58:46 -0400
Subject: [Pythonmac-SIG] py2app error
In-Reply-To: <D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>
References: <4DD5585D-1E8F-4D26-955A-43BCF01F50FF@gmail.com>
	<A4F1AE89-6EAB-4652-8CFD-BAE7AAB9D278@mac.com>
	<53F2A68A-9415-474D-88EB-78A2F3E986A2@mac.com>
	<32CA16F6-27E7-45A8-9808-C58688D96A85@gmail.com>
	<F3589161-524F-42A5-B2B7-5DA9892AEEC6@mac.com>
	<FEC76414-302C-441C-85A5-4B02A74FCDB5@gmail.com>
	<D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>
Message-ID: <E35A97E9-B90C-452D-BCDC-40977E435D77@gmail.com>

I'm using the most recent 1.1.4 version of pyglet, which I installed  
from the binary and I'm using the 2.5.1 version of Python that shipped  
with OS X 10.5. Would updating python fix the problem?


On Aug 1, 2010, at 2:55 AM, Ronald Oussoren wrote:

>
> On 31 Jul, 2010, at 23:02, Nathan Lemoine wrote:
>
>> Running the testing application in the command line did confirm  
>> that the pyglet module isn't being found:
>>
>> File "/Users/Nate/dist/tester.app/Contents/Resources/__boot__.py",  
>> line 160, in _run
>>   execfile(path, globals(), globals())
>> File "/Users/Nate/Desktop/tester.py", line 1, in <module>
>>   import pyglet
>> ImportError: No module named pyglet
>>
>> Is there a way to manually add the path for pyglet to py2app's  
>> search or in the setup.py file to force the module to be loaded?
>
> This is very odd. Which version of Python do you use? And likewise  
> for pyglet?
>
> I've installed pyglet for python 2.6 using the 1.1.4 binary  
> installer on their site, and used "easy_install-2.7 pyglet" to  
> install the python parts for python 2.7. Both result in a working  
> application bundle.
>
> There is misfeature in pyglet that makes this bundle not-quite- 
> standalone though,  the pyglet sources explicitly load /usr/local/ 
> lib/libavbin.dylib using ctypes.  I could create a py2app recipe  
> that copies libavbin.dylib into the application bundle, but that  
> will probably not be used without patching the pyglet sources.
>
> I've attached the scripts I used to test.
>
> Ronald
>
> <setup.py><runner.py>
>>
>>
>> On Jul 30, 2010, at 1:54 AM, Ronald Oussoren wrote:
>>
>>>
>>> On 30 Jul, 2010, at 2:59, Nathan Lemoine wrote:
>>>
>>>> I installed the 0.5.2 update, and I've tried making just a very  
>>>> simple pyglet app to play a movie file so that you all could try  
>>>> it if you want on your python distributions:
>>>>
>>>> import pyglet
>>>>
>>>> vidPath="video.avi" ##put the path to a video file here
>>>> window = pyglet.window.Window()
>>>> source = pyglet.media.StreamingSource()
>>>> MediaLoad = pyglet.media.load(vidPath)
>>>> player = pyglet.media.Player()
>>>> player.queue(MediaLoad)
>>>> player.play()
>>>>
>>>> @window.event
>>>> def on_draw():
>>>> 	player.get_texture().blit(0,0)
>>>>
>>>> pyglet.app.run()
>>>
>>> Thanks for the demo, that will definitly help in reproducing and  
>>> fixing the problem.
>>>
>>>>
>>>> Executing python setup.py py2app still gives me the same error:
>>>>
>>>> Traceback (most recent call last):
>>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/ 
>>>> py2app/build_app.py", line 604, in _run
>>>> self.run_normal()
>>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/ 
>>>> py2app/build_app.py", line 675, in run_normal
>>>> self.create_binaries(py_files, pkgdirs, extensions, loader_files)
>>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/ 
>>>> py2app/build_app.py", line 739, in create_binaries
>>>> dry_run=self.dry_run)
>>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/ 
>>>> py2app/util.py", line 376, in byte_compile
>>>> if force or newer(mod.filename, cfile):
>>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/ 
>>>> py2app/util.py", line 172, in newer
>>>> msource = get_mtime(source)
>>>> File "/Library/Python/2.5/site-packages/py2app-0.5.2-py2.5.egg/ 
>>>> py2app/util.py", line 164, in get_mtime
>>>> info = zf.getinfo(rest)
>>>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
>>>> lib/python2.5/zipfile.py", line 462, in getinfo
>>>> return self.NameToInfo[name]
>>>> KeyError: 'pyglet/__init__.pyc'
>>>>> /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>>>>> python2.5/zipfile.py(462)getinfo()
>>>> -> return self.NameToInfo[name]
>>>> (Pdb)
>>>>
>>>> I ran it in alias mode as well and it bundled 'tester.app'  
>>>> successfully. When I attempted to run the bundle, I just got a  
>>>> dialog box that said 'tester Error' and brought me to the  
>>>> MacPython website. I'm not sure how to find out what the issue is  
>>>> with the aliased bundle.
>>>
>>> You can run the app from the command-line:  test.app/Contents/ 
>>> MacOS/tester
>>>
>>> When you do that you'll get error messages in your terminal  
>>> window, and those should explain what's going on.  I expect that  
>>> pyglet cannot be found.
>>>
>>>>
>>>> Thanks for the help so far! I really appreciate it. I don't think  
>>>> I could figure this out on my own
>>>
>>> I haven't had time to look into this issue specifically, I'll do  
>>> so in the near future.
>>>
>>> Ronald
>>>
>>>
>>>>
>>>>
>>>>
>>>> On Jul 29, 2010, at 2:34 AM, Ronald Oussoren wrote:
>>>>
>>>>>
>>>>> On 29 Jul, 2010, at 8:09, Ronald Oussoren wrote:
>>>>>
>>>>>>
>>>>>> On 28 Jul, 2010, at 18:38, Nathan Lemoine wrote:
>>>>>>
>>>>>>>
>>>>>>> Traceback (most recent call last):
>>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/ 
>>>>>>> py2app/build_app.py", line 602, in _run
>>>>>>> self.run_alias()
>>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/ 
>>>>>>> py2app/build_app.py", line 548, in run_alias
>>>>>>> dst = self.build_alias_executable(target, target.script)
>>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/ 
>>>>>>> py2app/build_app.py", line 1145, in build_alias_executable
>>>>>>> appdir, resdir, plist = self.create_bundle(target, script)
>>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/ 
>>>>>>> py2app/build_app.py", line 1131, in create_bundle
>>>>>>> use_runtime_preference=use_runtime_preference
>>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/ 
>>>>>>> py2app/build_app.py", line 1120, in create_appbundle
>>>>>>> extension=self.extension,
>>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/ 
>>>>>>> py2app/create_appbundle.py", line 34, in create_appbundle
>>>>>>> copy(srcmain, destmain)
>>>>>>> File "/Library/Python/2.5/site-packages/py2app-0.5-py2.5.egg/ 
>>>>>>> py2app/util.py", line 233, in mergecopy
>>>>>>> return macholib.util.mergecopy(src, dest)
>>>>>>> File "build/bdist.macosx-10.5-i386/egg/macholib/util.py", line  
>>>>>>> 111, in mergecopy
>>>>>>> copy2(src, dest)
>>>>>>> File "build/bdist.macosx-10.5-i386/egg/macholib/util.py", line  
>>>>>>> 43, in copy2
>>>>>>> shutil.copy2(fsencoding(src), fsencoding(dst))
>>>>>>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
>>>>>>> lib/python2.5/shutil.py", line 91, in copy2
>>>>>>> copyfile(src, dst)
>>>>>>> File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
>>>>>>> lib/python2.5/shutil.py", line 46, in copyfile
>>>>>>> fsrc = open(src, 'rb')
>>>>>>> IOError: [Errno 2] No such file or directory: '/Library/Python/ 
>>>>>>> 2.5/site-packages/py2app-0.5-py2.5.egg/py2app/apptemplate/ 
>>>>>>> prebuilt/main-i386'
>>>>>>>> /System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>>>>>>>> python2.5/shutil.py(53)copyfile()
>>>>>>> -> fsrc.close()
>>>>>>>
>>>>>>> I went into the Python Framework folder and the only prebuilt  
>>>>>>> executeable in there is 32bit one, there isn't a main-i386  
>>>>>>> file. Am I missing a file?
>>>>>>
>>>>>> You aren't missing a file, py2app doesn't have a main-i386  
>>>>>> file.  As a quick workaround you can copy /Library/Python/2.5/ 
>>>>>> site-packages/py2app-0.5-py2.5.egg/py2app/apptemplate/prebuilt/ 
>>>>>> main-fat  to /Library/Python/2.5/site-packages/py2app-0.5- 
>>>>>> py2.5.egg/py2app/apptemplate/prebuilt/main-i386.
>>>>>>
>>>>>> I will tweak py2app to better handle this, that will be in the  
>>>>>> next release (0.5.2, hopefully later this week).
>>>>>
>>>>> I've upload py2app 0.5.2. With this version I can build a pyobjc  
>>>>> application using python 2.5 (without the IOError exception),  
>>>>> the pyglet error is not yet fixed.
>>>>>
>>>>> Ronald
>>>>>
>>>>
>>>
>>
>


From Chris.Barker at noaa.gov  Mon Aug  2 03:27:05 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Sun, 01 Aug 2010 18:27:05 -0700
Subject: [Pythonmac-SIG] py2app error
In-Reply-To: <DD38B830-00D1-48D3-8975-4F5A802CB103@mac.com>
References: <4DD5585D-1E8F-4D26-955A-43BCF01F50FF@gmail.com>
	<A4F1AE89-6EAB-4652-8CFD-BAE7AAB9D278@mac.com>
	<53F2A68A-9415-474D-88EB-78A2F3E986A2@mac.com>
	<32CA16F6-27E7-45A8-9808-C58688D96A85@gmail.com>
	<F3589161-524F-42A5-B2B7-5DA9892AEEC6@mac.com>
	<FEC76414-302C-441C-85A5-4B02A74FCDB5@gmail.com>
	<D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>
	<4C55A9FE.7070909@noaa.gov>
	<DD38B830-00D1-48D3-8975-4F5A802CB103@mac.com>
Message-ID: <4C561EE9.4070204@noaa.gov>

Ronald Oussoren wrote:
>> This is a problem in general with all ctypes uses. In fact, ctypes
>> reminds me a bit of py2app in the sense that it has some built-in
>> algorithms for searching for dynamic libs, and that these fail fairly often.
> 
> Please file bugs for that, I'm pretty sure that ctypes is supposed to
> implement the same algoritms as the platform dynamic linker.

IIUC, on OS-X, the full path to a dll is specified when linked -- it 
sure seems that way.

So there is no "normal search path".  But anyway, what I've seen is 
pacakges that don't find macports stuff, etc.

I've had to patch the package to make it work at all -- I haven't tried 
to us py2app on any of those yet though. When I do, I'll post a bug 
report here, though.

> W.r.t. py2app: I consider cases where py2app doesn't find modules or
> shared libraries bugs and should be fixed, either by making the core
> smarter or by adding recipes.   Please post reports about issues,
> especially when you can reproduce them in smallish examples (or at
> least examples that you can share with the outside world).

will do.

But there aer some cases where dynamic importing is simpily goign to 
fail, and you can get a lot of those covered with recipes that bring in 
big 'ol packages that aren't needed, but I'm not sure I always want that.

And if the dynamic import is part of your own code, then it shouldn't be 
a recipe anyway.

But yes, the mainstream packages should all "just work".

>> As for py2app, maybe the ctypes recipe could patch ctypes to look
>> in a particular place in the bundle, and then the user could
>> specify which libs ctypes used, and py2ap would put them in the
>> bundle.
> 
> Yes, but that will require some additional trickery to ensure that
> ctypes looks in this special location before looking at the full name
> specified by the caller.

yup. Maybe not worth it.

> Actually finding which libraries are loaded using ctypes will sadly
> enough be impossible in general, although recipes could be used for
> the popular libaries.

Agreed.

Thanks,

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From grubert at users.sourceforge.net  Mon Aug  2 11:23:01 2010
From: grubert at users.sourceforge.net (engelbert gruber)
Date: Mon, 2 Aug 2010 11:23:01 +0200
Subject: [Pythonmac-SIG] Installing Mysqldb Module on Python 2.5.1 on
	Mac OS X 10.5.8
In-Reply-To: <AANLkTikbtrMif-pAbe=YP0OYnScuiCQMqnDhz+HFxxvX@mail.gmail.com>
References: <AANLkTikbtrMif-pAbe=YP0OYnScuiCQMqnDhz+HFxxvX@mail.gmail.com>
Message-ID: <AANLkTinTg-O3pFcgoHvkiB3ZfwN=CbQqhbAcEXHgAVSF@mail.gmail.com>

hi,

i am new on the mac too, but somehow managed to build mysqldb

as far as i remeber, it requires a mysql installation and the new xcode.

i did not install Mysqldb but copied it into my project directory
(which now bites back: py2app packages it but python only looks in
 usr/lib/...)

did it build ?

On Fri, Jul 30, 2010 at 4:23 PM, Muthoni Masinde
<muthonimasinde at gmail.com> wrote:
> Hello everyone,
> I am a new entrant to Python (but not new in programming).? I am trying to
> install the mysqldb module on my Mac OS in vain.? I have tried all the
> instructions in the README.
>
> I keep getting the following error
>
> setup_posix.py", line 32, in get_config
> ??? metadata, options = get_metadata_and_options()
> ? File
> "/Users/Muthoni/phd2010/Thesis/software/Python/MySQL-python-1.2.3/setup_common.py",
> line 7, in get_metadata_and_options
> ??? metadata = dict(config.items('metadata'))
> ? File
> "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ConfigParser.py",
> line 544, in items
> ConfigParser.NoSectionError: No section: 'metadata'
>
> Someone please help.
>
> Thank you very much,
> Muthoni
>
> _______________________________________________
> 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
>
>

From muthonimasinde at gmail.com  Mon Aug  2 18:42:34 2010
From: muthonimasinde at gmail.com (Muthoni Masinde)
Date: Mon, 2 Aug 2010 19:42:34 +0300
Subject: [Pythonmac-SIG] Installing Mysqldb Module on Python 2.5.1 on
	Mac OS X 10.5.8
In-Reply-To: <AANLkTinTg-O3pFcgoHvkiB3ZfwN=CbQqhbAcEXHgAVSF@mail.gmail.com>
References: <AANLkTikbtrMif-pAbe=YP0OYnScuiCQMqnDhz+HFxxvX@mail.gmail.com>
	<AANLkTinTg-O3pFcgoHvkiB3ZfwN=CbQqhbAcEXHgAVSF@mail.gmail.com>
Message-ID: <AANLkTi=Nhkr=N+sEZBacQ4MCiC08L9xRm9xBwPpLnCMw@mail.gmail.com>

Thank you Gruber,
Let me try your suggestion out
Muthoni


On Mon, Aug 2, 2010 at 12:23 PM, engelbert gruber <
grubert at users.sourceforge.net> wrote:

> hi,
>
> i am new on the mac too, but somehow managed to build mysqldb
>
> as far as i remeber, it requires a mysql installation and the new xcode.
>
> i did not install Mysqldb but copied it into my project directory
> (which now bites back: py2app packages it but python only looks in
>  usr/lib/...)
>
> did it build ?
>
> On Fri, Jul 30, 2010 at 4:23 PM, Muthoni Masinde
> <muthonimasinde at gmail.com> wrote:
> > Hello everyone,
> > I am a new entrant to Python (but not new in programming).  I am trying
> to
> > install the mysqldb module on my Mac OS in vain.  I have tried all the
> > instructions in the README.
> >
> > I keep getting the following error
> >
> > setup_posix.py", line 32, in get_config
> >     metadata, options = get_metadata_and_options()
> >   File
> >
> "/Users/Muthoni/phd2010/Thesis/software/Python/MySQL-python-1.2.3/setup_common.py",
> > line 7, in get_metadata_and_options
> >     metadata = dict(config.items('metadata'))
> >   File
> >
> "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/ConfigParser.py",
> > line 544, in items
> > ConfigParser.NoSectionError: No section: 'metadata'
> >
> > Someone please help.
> >
> > Thank you very much,
> > Muthoni
> >
> > _______________________________________________
> > 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100802/86408d70/attachment.html>

From rowen at uw.edu  Mon Aug  2 23:55:21 2010
From: rowen at uw.edu (Russell E. Owen)
Date: Mon, 02 Aug 2010 14:55:21 -0700
Subject: [Pythonmac-SIG] ANN: py2app 0.5
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>
Message-ID: <rowen-17C4B2.14552102082010@news.gmane.org>

In article <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7 at mac.com>,
 Ronald Oussoren <ronaldoussoren at mac.com> wrote:

> Hi,
> 
> I've just uploaded py2app 0.5 and new versions of altgraph, modulegraph and 
> macholib. I hope this solves most issues with py2app.   "easy_install-X.Y -U 
> py2app" should install the software for you (where X.Y is your favorite 
> version of Python)
> 
> There is one new feature in this release: experimental support for python 3.  
>  This basicly means that I managed to build a single application as a 
> standalone application bundle, without much testing.   Alias builds and 
> plugin bundles almost certainly don't work (the first because alias builds 
> use the Carbon module which isn't available in python 3, the latter because I 
> had to rewrite the C code in the application bundles and probably have to do 
> the same for plugin bundles).
> 
> Ronald---------------------------------------------------------------------

It works for me.

I updated to py2app 0.5.2 using:
pip install --upgrade py2app

I then removed an extra blank __init__.py file I'd put in my zope 
directly to work around an issue with my earlier py2app (zope.interface 
was installed using pip, which uses a complex .pth file).

Finally I build a complex application with py2app and it worked 
perfectly (I double checked by moving my Python Tcl and Tk frameworks 
out of the way).

Thank you very much for the update!

-- Russell

P.S. I'm curious about the virtualenv improvements. I use virtualenv to 
develop my code, but when I've got the appropriate environment set up if 
I build the application using py2app I always get the appended traceback 
(even witih py2app 0.5.2).

To work around it I have my setup.py script add a few necessary bits to 
sys.path and I build from a fresh login with no virtual environment set 
up.

No big deal, but if there is a way to make the build work even when the 
required packages are setup using virutalenv, I'd like to know about it.

Building Mac version
*** using recipe: virtualenv ***
*** using recipe: PIL ***
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac
kages/py2app/build_app.py", line 589, in _run
    self.run_normal()
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac
kages/py2app/build_app.py", line 645, in run_normal
    self.process_recipes(mf, filters, flatpackages, loader_files)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac
kages/py2app/build_app.py", line 559, in process_recipes
    rval = check(self, mf)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac
kages/py2app/recipes/matplotlib.py", line 5, in check
    mf.import_hook('pytz.zoneinfo', m, ['UTC'])
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac
kages/modulegraph/modulegraph.py", line 401, in import_hook
    m = self.load_tail(q, tail)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-pac
kages/modulegraph/modulegraph.py", line 464, in load_tail
    raise ImportError, "No module named " + mname
ImportError: No module named pytz.zoneinfo
> /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/modulegraph/modulegraph.py(464)load_tail()
-> raise ImportError, "No module named " + mname


From matthias.baas at gmail.com  Mon Aug  2 23:55:16 2010
From: matthias.baas at gmail.com (Matthias Baas)
Date: Mon, 02 Aug 2010 22:55:16 +0100
Subject: [Pythonmac-SIG] Py2app too complex?
In-Reply-To: <4C55AEEB.7060203@noaa.gov>
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>	<AANLkTinhiH-=SO9PRhGS=Szwbg2zs=S0OQBwtwc-u4Th@mail.gmail.com>	<4C5377B8.2080105@canterbury.ac.nz>
	<4C55AEEB.7060203@noaa.gov>
Message-ID: <4C573EC4.3090807@gmail.com>

Christopher Barker wrote:
> Greg Ewing wrote:
>> I've been thinking for a while about creating something
>> simpler that doesn't attempt any automatic module discovery
>> at all. You would be required to construct a project file
>> that explicitly lists all the required modules and libraries,
>> including standard library modules.
> 
> I've thought for a while that there is way too much re-invention of the
> wheel with the various stand-alone builders. I'd love to see more
> flexibility, and ideally code sharing, by breaking down the process into
> the various parts:
> 
> [...]
> So, aside from allowing more code sharing, this approach would make it
> easier to plug in different pieces, like Greg's proposed manual
> specification of modules.
> 
> As for that proposal -- I agree with other posters that that really
> would be onerous. However, a hybrid would be great -- run some sort of
> automated tool that outputs an easy-to-read-and-edit text file that
> could be edited, and have the bundle builder use that. Then you culd
> e3dit it, write it frm scratch, whatever you like.

Is anyone here familiar with Py++ [1]? What Christopher describes
reminded me very much of that tool. Py++ is not a tool to produce
standalone packages like py2app does, instead it's a tool to generate
Python bindings for C/C++ libraries, but it seems their inner workings
share similarities. Just like py2app has to find out what modules get
imported by an application, Py++ needs to find out what
functions/classes are in a library and which of them need to be turned
into Python functions/classes. Py++ does that by running gccxml on the
header files to extract the contents of the files which is then further
processed. For simple libraries it might be enough to let Py++ just
convert everything it finds in the headers, but for more complex
libraries you want to customize that and leave out some stuff.
Now the thing is, Py++ is not implemented as a standalone tool you just
run on some input files, but instead, it's a framework for writing
wrapper generators. This means, the user writes the main script (in
Python) which invokes Py++ functionality and this means the actual
control of the entire process is in the user's hands.
In simple cases, it's enough to leave everything up to Py++ which means
your main script will be very short. But if you want to, you can
intercept any step in the processing pipeline and modify the data. For
example, as mentioned above, the first step is to get the declarations
from the header files which builds a tree of declarations that's stored
in memory. Before the tree is passed on, your main script can inspect
and modify it. You could even choose to skip that gccxml step entirely
and produce the declaration tree by some other means. Subsequent Py++
steps just work on that tree, it doesn't matter anymore who created it.
After that, the wrapper source code is generated which is again a tree
of text blocks. Before this tree is written to disk to generate the
source files, you can again intercept this and modify the tree.
This design makes Py++ very flexible because you can inject your own
logic into the pipeline to tailer the process to your needs.
Now it sounds like exactly the same thing could be done in py2app (which
I have never used so far, by the way, but from reading the mails here it
sounds like it doesn't already provide this sort of flexibilty). Its
first step is to find out what modules need to be included. If this
produces a well-defined data structure with an API to modify/create it
and the user gets the chance to modify that data before it's passed on
(or even recreate it from scratch), then all use-cases that have been
mentioned here could be handled by the same tool.

Sorry if this all doesn't make any sense or py2app already has different
means of achieving this flexibilty. As I said, I haven't used py2app yet
(but it's on my todo list to try it out), it's just because
Christopher's mail sounded so much like Py++ that I thought I'd chime in
for a moment.

Cheers,

- Matthias -

[1] http://www.language-binding.net/


From ronaldoussoren at mac.com  Tue Aug  3 09:53:09 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Aug 2010 09:53:09 +0200
Subject: [Pythonmac-SIG] [Pyobjc-dev]  Py2app too complex?
In-Reply-To: <4C55AEEB.7060203@noaa.gov>
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>
	<AANLkTinhiH-=SO9PRhGS=Szwbg2zs=S0OQBwtwc-u4Th@mail.gmail.com>
	<4C5377B8.2080105@canterbury.ac.nz> <4C55AEEB.7060203@noaa.gov>
Message-ID: <0F60BF11-2872-4B59-A170-5408437A048B@mac.com>


On 1 Aug, 2010, at 19:29, Christopher Barker wrote:

> Greg Ewing wrote:
>> I've been thinking for a while about creating something
>> simpler that doesn't attempt any automatic module discovery
>> at all. You would be required to construct a project file
>> that explicitly lists all the required modules and libraries,
>> including standard library modules.
> 
> I've thought for a while that there is way too much re-invention of the 
> wheel with the various stand-alone builders. I'd love to see more 
> flexibility, and ideally code sharing, by breaking down the process into 
> the various parts:

> 1) the API for specifying what you need built -- py2app and py2exe at 
> least share much )but not all) of this, though they are slightly 
> incompatible. AFAIK, the rest are all different

AFAIK Bob intented py2app to be compatible with py2exe when specifying what to build. That won't always work though due to differences between the two platforms.

It might be useful to think about a cleaner way to specify what to build, I don't particularly like the current way and especially not when building more complex applications.

> 
> 2) Figuring out what needs to be included. py2app and bbfreeze both use 
> modulegraph, though bb-freeze apparently forked it.

Correct. I don't know what py2exe uses, it might use the stdlib modulefinder.

> 
> 3) Actually building the bundle -- by definition this will be different 
> on different platforms, and there are multiple ways of doing it on one 
> platform
> 
> Anyway, ideally, each of these steps could share a common API, and so 
> each bundle builder could mix and match the parts as they saw fit.
> 
> Getting everyone to cooperate is a big social, rather then technical 
> problem, but py2app at least could be designed to allow each of these 
> pieces to be replaceable. (maybe it already is -- I haven't poked into 
> the code enough to know)
> 
> So, aside from allowing more code sharing, this approach would make it 
> easier to plug in different pieces, like Greg's proposed manual 
> specification of modules.

I totally agree that is would be better to try to get the various stand-alone builders to at least share code for the common functionality. A common API for the various components would help with that, but it would IMHO be better to actually merge the various components.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100803/bec6c12d/attachment-0001.bin>

From ronaldoussoren at mac.com  Tue Aug  3 10:24:00 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Aug 2010 10:24:00 +0200
Subject: [Pythonmac-SIG] py2app error
In-Reply-To: <4C561EE9.4070204@noaa.gov>
References: <4DD5585D-1E8F-4D26-955A-43BCF01F50FF@gmail.com>
	<A4F1AE89-6EAB-4652-8CFD-BAE7AAB9D278@mac.com>
	<53F2A68A-9415-474D-88EB-78A2F3E986A2@mac.com>
	<32CA16F6-27E7-45A8-9808-C58688D96A85@gmail.com>
	<F3589161-524F-42A5-B2B7-5DA9892AEEC6@mac.com>
	<FEC76414-302C-441C-85A5-4B02A74FCDB5@gmail.com>
	<D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>
	<4C55A9FE.7070909@noaa.gov>
	<DD38B830-00D1-48D3-8975-4F5A802CB103@mac.com>
	<4C561EE9.4070204@noaa.gov>
Message-ID: <A1054428-EB19-4A68-AC79-918E26E97269@mac.com>


On 2 Aug, 2010, at 3:27, Christopher Barker wrote:

> Ronald Oussoren wrote:
>>> This is a problem in general with all ctypes uses. In fact, ctypes
>>> reminds me a bit of py2app in the sense that it has some built-in
>>> algorithms for searching for dynamic libs, and that these fail fairly often.
>> Please file bugs for that, I'm pretty sure that ctypes is supposed to
>> implement the same algoritms as the platform dynamic linker.
> 
> IIUC, on OS-X, the full path to a dll is specified when linked -- it sure seems that way.
> 
> So there is no "normal search path".  But anyway, what I've seen is pacakges that don't find macports stuff, etc.
> 
> I've had to patch the package to make it work at all -- I haven't tried to us py2app on any of those yet though. When I do, I'll post a bug report here, though.

It would be better to post ctypes issues on bugs.python.org, that way the issue won't get lost and all python contributers can see the issue and work on it.

> 
>> W.r.t. py2app: I consider cases where py2app doesn't find modules or
>> shared libraries bugs and should be fixed, either by making the core
>> smarter or by adding recipes.   Please post reports about issues,
>> especially when you can reproduce them in smallish examples (or at
>> least examples that you can share with the outside world).
> 
> will do.
> 
> But there aer some cases where dynamic importing is simpily goign to fail, and you can get a lot of those covered with recipes that bring in big 'ol packages that aren't needed, but I'm not sure I always want that.

Dynamic imports will always be a problem, and we need a way to specify the required behaviour in the setup.py script. As an example, when I use SQLAlchemy in a project there should be a clean way to specify which drivers I want in the setup.py script, and the SQLAlchemy recipe should have a way to get to this information and should also have a way to error out when the user hasn't specified which database drivers he wants.

> 
> And if the dynamic import is part of your own code, then it shouldn't be a recipe anyway.

Maybe, maybe not.  I wouldn't mind adding a public API for external recipes, that way you could add recipes for your own libraries.

> 
> But yes, the mainstream packages should all "just work".
> 
>>> As for py2app, maybe the ctypes recipe could patch ctypes to look
>>> in a particular place in the bundle, and then the user could
>>> specify which libs ctypes used, and py2ap would put them in the
>>> bundle.
>> Yes, but that will require some additional trickery to ensure that
>> ctypes looks in this special location before looking at the full name
>> specified by the caller.
> 
> yup. Maybe not worth it.

I haven't looked at the ctypes code yet. I would be worth it if it can be done with little effort, but not when it requires major engineering.

> 
>> Actually finding which libraries are loaded using ctypes will sadly
>> enough be impossible in general, although recipes could be used for
>> the popular libaries.
> 
> Agreed.
> 
> Thanks,
> 
> -Chris
> 

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100803/62378149/attachment.bin>

From ronaldoussoren at mac.com  Tue Aug  3 10:26:35 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 03 Aug 2010 10:26:35 +0200
Subject: [Pythonmac-SIG] ANN: py2app 0.5
In-Reply-To: <rowen-17C4B2.14552102082010@news.gmane.org>
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>
	<rowen-17C4B2.14552102082010@news.gmane.org>
Message-ID: <D4A48832-17E3-43C7-BFA6-4CB143240750@mac.com>


On 2 Aug, 2010, at 23:55, Russell E. Owen wrote:

> 
> 
> P.S. I'm curious about the virtualenv improvements. I use virtualenv to 
> develop my code, but when I've got the appropriate environment set up if 
> I build the application using py2app I always get the appended traceback 
> (even witih py2app 0.5.2).
> 
> To work around it I have my setup.py script add a few necessary bits to 
> sys.path and I build from a fresh login with no virtual environment set 
> up.
> 
> No big deal, but if there is a way to make the build work even when the 
> required packages are setup using virutalenv, I'd like to know about it.

That's strange, I have build a couple of applications using virtualenvs. I don't use pip though and have patches to virtualenv that might change its behavior enough the explain the difference.  Another set of patches to push upstream...

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100803/a8ccabe2/attachment.bin>

From Chris.Barker at noaa.gov  Tue Aug  3 18:18:24 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Aug 2010 09:18:24 -0700
Subject: [Pythonmac-SIG] py2app error
In-Reply-To: <A1054428-EB19-4A68-AC79-918E26E97269@mac.com>
References: <4DD5585D-1E8F-4D26-955A-43BCF01F50FF@gmail.com>
	<A4F1AE89-6EAB-4652-8CFD-BAE7AAB9D278@mac.com>
	<53F2A68A-9415-474D-88EB-78A2F3E986A2@mac.com>
	<32CA16F6-27E7-45A8-9808-C58688D96A85@gmail.com>
	<F3589161-524F-42A5-B2B7-5DA9892AEEC6@mac.com>
	<FEC76414-302C-441C-85A5-4B02A74FCDB5@gmail.com>
	<D5B2323E-3761-4B33-B2DC-E1694DE46DF2@mac.com>
	<4C55A9FE.7070909@noaa.gov>
	<DD38B830-00D1-48D3-8975-4F5A802CB103@mac.com>
	<4C561EE9.4070204@noaa.gov>
	<A1054428-EB19-4A68-AC79-918E26E97269@mac.com>
Message-ID: <4C584150.1000603@noaa.gov>

Ronald Oussoren wrote:
> It would be better to post ctypes issues on bugs.python.org, that way the issue won't get lost and all python contributers can see the issue and work on it.


Agreed, though I think the case I'm thinking of is more an issue with 
the package than with ctypes itself -- ctypes can only do so much.

(the case is the PyEnchant package, with wraps the enchant spell 
checking library, which wraps various actual spell checking libs -- it's 
a bit of a mess, inherently). If anyone cares, I've messed with this to 
get spell shccking workign with the Peppy editor. I haev yet to get a 
proper py2app build of Peppy, which I would like to do, but haven't 
found the time.


> Dynamic imports will always be a problem, and we need a way to
> specify the required behaviour in the setup.py script. As an example, when I use
> SQLAlchemy in a project there should be a clean way to specify which
> drivers I want in the setup.py script, and the SQLAlchemy recipe should
> have a way to get to this information and should also have a way to
> error out when the user hasn't specified which database drivers he wants.

yup -- another issue I"ve run into is packages that rely on setuptools 
"require" -- at least I think it's "require" -- anyway, I built a 
Pylons-based app, and it was a serious pain because it uses setuptools 
to determine which versions of various things to use at runtime -- so to 
get it all to work, you need to include all kinds of stuff you aren't 
using in the bundle -- various deprecated packages, etc. Personally, I 
think that's a bug in Pylons -- it should do version and package 
selection at install time, not run time, so I don't know that py2app 
should work around that kind of mess.

>> And if the dynamic import is part of your own code, then it
>> shouldn't
>> be a recipe anyway.
> 
> Maybe, maybe not. I wouldn't mind adding a public API for external
recipes, that way you could add recipes for your own libraries.

I like that idea.

>>>> As for py2app, maybe the ctypes recipe could patch ctypes to look
>>>> in a particular place in the bundle, and then the user could
>>>> specify which libs ctypes used, and py2ap would put them in the
>>>> bundle.
>>> Yes, but that will require some additional trickery to ensure that
>>> ctypes looks in this special location before looking at the full name
>>> specified by the caller.
>> yup. Maybe not worth it.
> 
> I haven't looked at the ctypes code yet. I would be worth it if it
> can be done with little effort, but not when it requires major
> engineering.

If you can find the time, that would be great!


Thanks again for all your work in this.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From Chris.Barker at noaa.gov  Tue Aug  3 18:24:09 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 03 Aug 2010 09:24:09 -0700
Subject: [Pythonmac-SIG] [Pyobjc-dev]  Py2app too complex?
In-Reply-To: <0F60BF11-2872-4B59-A170-5408437A048B@mac.com>
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>
	<AANLkTinhiH-=SO9PRhGS=Szwbg2zs=S0OQBwtwc-u4Th@mail.gmail.com>
	<4C5377B8.2080105@canterbury.ac.nz> <4C55AEEB.7060203@noaa.gov>
	<0F60BF11-2872-4B59-A170-5408437A048B@mac.com>
Message-ID: <4C5842A9.2020508@noaa.gov>

Ronald Oussoren wrote:
> AFAIK Bob intented py2app to be compatible with py2exe when
> specifying what to build. That won't always work though due
 > to differences between the two platforms.

There are differences that are because of platform. I think datafiles 
are handles differently at least.

If you want to consider those bugs, I could try to dig into some of my 
setups and identify the issues I've found -- but that won't be for a 
couple weeks at least (vacation!)


> It might be useful to think about a cleaner way to specify what to
> build, I don't particularly like the current way and especially not when
> building more complex applications.

agreed -- though it's no horrible.

> I totally agree that is would be better to try to get the various
> stand-alone builders to at least share code for the common
> functionality. A common API for the various components would help
> with that, but it would IMHO be better to actually merge the various
> components.

Me too, but that requires cooperation, which may be hard to come by. I'd 
at least contact the ebb-freeze guy (Ralf?) -- he seemed a little 
confused about how to share code -- for instance, he said he couldn't 
use py2exe's code for including the icon because of licensing, but it 
looked like the license was compatible to me. With a little 
encouragement, maybe he'd be glad to share more.

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From half.italian at gmail.com  Wed Aug  4 01:28:40 2010
From: half.italian at gmail.com (Sean DiZazzo)
Date: Tue, 3 Aug 2010 16:28:40 -0700
Subject: [Pythonmac-SIG] Appscript unpredictable error
Message-ID: <AANLkTi=rz4vU_X7_Se6h6mZrK8=NGQ5yxMCSRSzdEWbM@mail.gmail.com>

Hi,

I'm using appscript to do some work in Quicktime, and it keeps erroring out
somewhat unpredictably.  I am opening and closing lots of documents in quick
succession when it happens.  It doesn't happen every time, but about 70%-80%
of the time.  When it errors, it always errors trying to make a new
document. ie. "qt.make(new=k.document)"  Quicktime will quit unexpectedly,
and after about 30 seconds I get:

OSERROR: -609
MESSAGE: Connection is invalid.
COMMAND: app(u'/Applications/QuickTime Player.app').make(new=k.document)

I have also gotten error #1708:"the AppleEvent was not handled by any
handler", but I can't seem to recreate the error.

I tried putting in a time.sleep(1), before making the new document, but it
didn't seem to help.  Any ideas?

~Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100803/47105353/attachment.html>

From ronaldoussoren at mac.com  Wed Aug  4 08:18:31 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Wed, 04 Aug 2010 08:18:31 +0200
Subject: [Pythonmac-SIG] [Pyobjc-dev]  Py2app too complex?
In-Reply-To: <4C5842A9.2020508@noaa.gov>
References: <2E51FD64-BD00-4BD6-BCA8-89E48A672FA7@mac.com>
	<AANLkTinhiH-=SO9PRhGS=Szwbg2zs=S0OQBwtwc-u4Th@mail.gmail.com>
	<4C5377B8.2080105@canterbury.ac.nz> <4C55AEEB.7060203@noaa.gov>
	<0F60BF11-2872-4B59-A170-5408437A048B@mac.com>
	<4C5842A9.2020508@noaa.gov>
Message-ID: <83C26049-9617-45D3-ACA3-639E23BE5484@mac.com>


On 3 Aug, 2010, at 18:24, Christopher Barker wrote:

> Ronald Oussoren wrote:
>> AFAIK Bob intented py2app to be compatible with py2exe when
>> specifying what to build. That won't always work though due
>> to differences between the two platforms.
> 
> There are differences that are because of platform. I think datafiles 
> are handles differently at least.
> 
> If you want to consider those bugs, I could try to dig into some of my 
> setups and identify the issues I've found -- but that won't be for a 
> couple weeks at least (vacation!)

This has no hurry, but I at least want to know about differences and document them.  And all differences that don't have a good reason should probably be fixed.

> 
> 
>> It might be useful to think about a cleaner way to specify what to
>> build, I don't particularly like the current way and especially not when
>> building more complex applications.
> 
> agreed -- though it's no horrible.
> 
>> I totally agree that is would be better to try to get the various
>> stand-alone builders to at least share code for the common
>> functionality. A common API for the various components would help
>> with that, but it would IMHO be better to actually merge the various
>> components.
> 
> Me too, but that requires cooperation, which may be hard to come by. I'd 
> at least contact the ebb-freeze guy (Ralf?) -- he seemed a little 
> confused about how to share code -- for instance, he said he couldn't 
> use py2exe's code for including the icon because of licensing, but it 
> looked like the license was compatible to me. With a little 
> encouragement, maybe he'd be glad to share more.

My first goal is to go through the py2app stack to fix small issues and add proper testing, after that I'm open for cooperation. 

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100804/bbdfb3f7/attachment.bin>

From hengist.podd at virgin.net  Thu Aug  5 18:35:51 2010
From: hengist.podd at virgin.net (has)
Date: Thu, 5 Aug 2010 17:35:51 +0100
Subject: [Pythonmac-SIG] Appscript unpredictable error
In-Reply-To: <mailman.48.1280916007.1656.pythonmac-sig@python.org>
References: <mailman.48.1280916007.1656.pythonmac-sig@python.org>
Message-ID: <141F2813-E961-4692-9008-B982A9936D3F@virgin.net>

Sean DiZazzo wrote:

> I'm using appscript to do some work in Quicktime, and it keeps  
> erroring out somewhat unpredictably.  I am opening and closing lots  
> of documents in quick succession when it happens.  It doesn't happen  
> every time, but about 70%-80% of the time.  When it errors, it  
> always errors trying to make a new document. ie.  
> "qt.make(new=k.document)"  Quicktime will quit unexpectedly, and  
> after about 30 seconds I get:
>
> OSERROR: -609
> MESSAGE: Connection is invalid.

That means the target application unexpectedly terminated (i.e.  
crashed) while your script was waiting for a reply. I would suggest  
filing a bug report on QuickTime Player <http://bugreport.apple.com>,  
ideally including an AppleScript that reproduces the problem.

HTH

has
-- 
Learn AppleScript, 3rd edition, Sanderson & Rosenthal:
http://apress.com/book/view/9781430223610
Control AppleScriptable applications from Python, Ruby and ObjC:
http://appscript.sourceforge.net


From sridharr at activestate.com  Thu Aug 12 22:03:01 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Thu, 12 Aug 2010 13:03:01 -0700
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
Message-ID: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>

When Python 2.6 is built with --universal-archs=intel, the default Python binary is symlinked to the 32-bit binary:

  lrwxr-xr-x  1 root  admin     12 10 Aug 15:31 python -> python2.6-32

Python 2.7, however, is 64-bit by default. Is there a particular reason why this behaviour is different for 2.6 (and 3.1)?

-srid

From nad at acm.org  Fri Aug 13 02:54:12 2010
From: nad at acm.org (Ned Deily)
Date: Thu, 12 Aug 2010 17:54:12 -0700
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
Message-ID: <nad-36924A.17541212082010@news.gmane.org>

In article <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD at activestate.com>,
 Sridhar Ratnakumar <sridharr at activestate.com> wrote:

> When Python 2.6 is built with --universal-archs=intel, the default Python 
> binary is symlinked to the 32-bit binary:
> 
>   lrwxr-xr-x  1 root  admin     12 10 Aug 15:31 python -> python2.6-32
> 
> Python 2.7, however, is 64-bit by default. Is there a particular reason why 
> this behaviour is different for 2.6 (and 3.1)?

For 2.7 and (upcoming) 3.2, code was added to allow dynamic selection of 
arch of a universal Python build, like so:

   arch -i386 /usr/local/bin/python2.7
   arch -x86_64 /usr/local/bin/python2.7

Without the use of arch, OS X defaults to an appropriate default, on 
10.6 preferring x86_64 if available.

On earlier versions like 2.6 and 3.1, the "arch" trick does not work 
because an execv(2) was used in the "wrapper" program 
(Mac/Tools/pythonw.c) to run the real interpreter and that causes the 
interpreter to run in the OS's preferred arch.  The new releases 
modified pythonw.c to use posix_spawnv(2) to ensure the interpreter is 
started using the same CPU arch as the wrapper program is running in.  
(The Apple-supplied /usr/bin/python in 10.6 takes a somewhat different 
approach to the problem.)

n the earlier versions (2.6/3.1 and earlier), the solution for universal 
variants with 32-/64-bit archs was to install separate 32-bit-only and 
64-bit-only interpreter executable files and install separate wrapper 
programs for each (python2.6-32 and python2.6-64) with the default names 
(python2.6/python) always symlinked to the 32-bit version.

It would be possible to backport the 2.7/3.2 solution to 2.6 but, as it 
affects both pythonw.c and various parts of the configure and make 
files, it's not likely to be done, certainly not for the imminent 2.6.6 
release.

-- 
 Ned Deily,
 nad at acm.org


From sridharr at activestate.com  Fri Aug 13 23:47:59 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 13 Aug 2010 14:47:59 -0700
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <nad-36924A.17541212082010@news.gmane.org>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
	<nad-36924A.17541212082010@news.gmane.org>
Message-ID: <78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>


On 2010-08-12, at 5:54 PM, Ned Deily wrote:

> In article <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD at activestate.com>,
> Sridhar Ratnakumar <sridharr at activestate.com> wrote:
> 
>> When Python 2.6 is built with --universal-archs=intel, the default Python 
>> binary is symlinked to the 32-bit binary:
>> 
>>  lrwxr-xr-x  1 root  admin     12 10 Aug 15:31 python -> python2.6-32
>> 
>> Python 2.7, however, is 64-bit by default. Is there a particular reason why 
>> this behaviour is different for 2.6 (and 3.1)?
> 
> For 2.7 and (upcoming) 3.2, code was added to allow dynamic selection of 
> arch of a universal Python build, like so:
> 
>   arch -i386 /usr/local/bin/python2.7
>   arch -x86_64 /usr/local/bin/python2.7
> 
> Without the use of arch, OS X defaults to an appropriate default, on 
> 10.6 preferring x86_64 if available.
> 
> On earlier versions like 2.6 and 3.1, the "arch" trick does not work 
> because an execv(2) was used in the "wrapper" program 
> (Mac/Tools/pythonw.c) to run the real interpreter and that causes the 
> interpreter to run in the OS's preferred arch.  The new releases 
> modified pythonw.c to use posix_spawnv(2) to ensure the interpreter is 
> started using the same CPU arch as the wrapper program is running in.  
> (The Apple-supplied /usr/bin/python in 10.6 takes a somewhat different 
> approach to the problem.)
> 
> n the earlier versions (2.6/3.1 and earlier), the solution for universal 
> variants with 32-/64-bit archs was to install separate 32-bit-only and 
> 64-bit-only interpreter executable files and install separate wrapper 
> programs for each (python2.6-32 and python2.6-64) with the default names 
> (python2.6/python) always symlinked to the 32-bit version.
> 
> It would be possible to backport the 2.7/3.2 solution to 2.6 but, as it 
> affects both pythonw.c and various parts of the configure and make 
> files, it's not likely to be done, certainly not for the imminent 2.6.6 
> release.

Thanks for the explanation. 

However, I see all three variants (32, 64, and 2-way) in the default 2.6.6c1 install (i.e., internal ActivePython build, though this is likely the case for the python.org's 10.5 installer as well):

-rwxr-xr-x  1 root  admin  12644 10 Aug 15:30 /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-32
-rwxr-xr-x  1 root  admin  12680 10 Aug 15:30 /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-64
-rwxr-xr-x  1 root  admin  24968 10 Aug 15:30 /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-all

But bin/python2.6 itself links to python2.6-32. What about changing that to python2.6-all - thus leaving the choice of arch to OS loader instead of the Python's build system?

Effectively, this change would likely come down to this patch:

sridharr at whymac:~/code/o/py/release26-maint/Mac > dif
Index: Makefile.in
===================================================================
--- Makefile.in (revision 83986)
+++ Makefile.in (working copy)
@@ -83,10 +83,10 @@
        ln -sf python$(VERSION)-all "$(DESTDIR)$(prefix)/bin/python-all"
        ln -sf pythonw$(VERSION)-all "$(DESTDIR)$(prefix)/bin/pythonw-all"
 
-       ln -sf pythonw$(VERSION)-32     "$(DESTDIR)$(prefix)/bin/pythonw$(VERSION)"
-       ln -sf python$(VERSION)-32      "$(DESTDIR)$(prefix)/bin/python$(VERSION)"
-       ln -sf pythonw$(VERSION)-32     "$(DESTDIR)$(prefix)/bin/pythonw"
-       ln -sf python$(VERSION)-32      "$(DESTDIR)$(prefix)/bin/python"
+       ln -sf pythonw$(VERSION)-all    "$(DESTDIR)$(prefix)/bin/pythonw$(VERSION)"
+       ln -sf python$(VERSION)-all     "$(DESTDIR)$(prefix)/bin/python$(VERSION)"
+       ln -sf pythonw$(VERSION)-all    "$(DESTDIR)$(prefix)/bin/pythonw"
+       ln -sf python$(VERSION)-all     "$(DESTDIR)$(prefix)/bin/python"
 
 #
 # Install unix tools in /usr/local/bin. These are just aliases for the 

Is this something that can become part of 2.6.6 final?

-srid


From nad at acm.org  Sat Aug 14 00:36:51 2010
From: nad at acm.org (Ned Deily)
Date: Fri, 13 Aug 2010 15:36:51 -0700
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
	<nad-36924A.17541212082010@news.gmane.org>
	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>
Message-ID: <nad-57167D.15365113082010@dough.gmane.org>

In article <78D65BDB-AB9C-4E8D-9440-4D071D3D8680 at activestate.com>,
 Sridhar Ratnakumar <sridharr at activestate.com> wrote:
>>[...]
> However, I see all three variants (32, 64, and 2-way) in the default 2.6.6c1 
> install (i.e., internal ActivePython build, though this is likely the case 
> for the python.org's 10.5 installer as well):
> 
> -rwxr-xr-x  1 root  admin  12644 10 Aug 15:30 
> /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-32
> -rwxr-xr-x  1 root  admin  12680 10 Aug 15:30 
> /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-64
> -rwxr-xr-x  1 root  admin  24968 10 Aug 15:30 
> /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-all
> 
> But bin/python2.6 itself links to python2.6-32. What about changing that to 
> python2.6-all - thus leaving the choice of arch to OS loader instead of the 
> Python's build system?

Off the top of my head (without testing it), I think that would lead to 
a potentially somewhat confusing situation where "bin/python2.6" means 
32-bit on 10.5 but 64-bit (or 32-bit, depending on the machine) on 10.6, 
with no possibility to override except by using the explicit 
python2.6-32 or python2.6-64 forms anyway.  Plus there is still the 
issue of Tk 8.4 vs 8.5: do you have a non-X 64-bit Tk that works on both 
10.5 and 10.6?

As for 2.6.6, it would be a bit of a moot point if Ronald doesn't plan 
to provide a 64-bit python.org installer for 2.6.6 as there haven't been 
any for earlier 2.6.x releases.  Of course, ActiveState and the other 
distributors of OS X installers could choose otherwise and, if so, patch 
it accordingly.  My opinion is that there are enough loose ends that it 
is better to focus on 64-bit support on 2.7/3.2 and on 10.6 (and higher) 
only.

-- 
 Ned Deily,
 nad at acm.org


From sridharr at activestate.com  Sat Aug 14 00:54:09 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 13 Aug 2010 15:54:09 -0700
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <nad-57167D.15365113082010@dough.gmane.org>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
	<nad-36924A.17541212082010@news.gmane.org>
	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>
	<nad-57167D.15365113082010@dough.gmane.org>
Message-ID: <BA29D3FD-F05A-4042-8F33-B92001959AC4@activestate.com>


On 2010-08-13, at 3:36 PM, Ned Deily wrote:

> In article <78D65BDB-AB9C-4E8D-9440-4D071D3D8680 at activestate.com>,
> Sridhar Ratnakumar <sridharr at activestate.com> wrote:
>>> [...]
>> However, I see all three variants (32, 64, and 2-way) in the default 2.6.6c1 
>> install (i.e., internal ActivePython build, though this is likely the case 
>> for the python.org's 10.5 installer as well):
>> 
>> -rwxr-xr-x  1 root  admin  12644 10 Aug 15:30 
>> /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-32
>> -rwxr-xr-x  1 root  admin  12680 10 Aug 15:30 
>> /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-64
>> -rwxr-xr-x  1 root  admin  24968 10 Aug 15:30 
>> /Library/Frameworks/Python.framework/Versions/2.6/bin/python2.6-all
>> 
>> But bin/python2.6 itself links to python2.6-32. What about changing that to 
>> python2.6-all - thus leaving the choice of arch to OS loader instead of the 
>> Python's build system?
> 
> Off the top of my head (without testing it), I think that would lead to 
> a potentially somewhat confusing situation where "bin/python2.6" means 
> 32-bit on 10.5 but 64-bit (or 32-bit, depending on the machine) on 10.6, 
> with no possibility to override except by using the explicit 
> python2.6-32 or python2.6-64 forms anyway.  

That can be said for the Python 2.7 Mac installer too, no? bin/python2.7 is a multi-arch binary, and bin/python symlinks to bin/python2.7.

sridharr at whymac:~/as/apy/trunk > ls -l /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7*
-rwxr-xr-x  1 root  admin  25656  4 Jul 14:02 /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
-rwxr-xr-x  1 root  admin  13580  4 Jul 14:02 /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-32
-rwxr-xr-x  1 root  admin   1663  4 Jul 14:02 /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config

> Plus there is still the 
> issue of Tk 8.4 vs 8.5: do you have a non-X 64-bit Tk that works on both 
> 10.5 and 10.6?

Not for 10.5 as, the requisite ActiveTcl 8.5 is i386 only, at the moment. On 10.6, ActivePython will work with Apple's Tcl/Tk (both i386 and x86_64).

> As for 2.6.6, it would be a bit of a moot point if Ronald doesn't plan 
> to provide a 64-bit python.org installer for 2.6.6 as there haven't been 
> any for earlier 2.6.x releases.  

Agreed. If there isn't going to be an official 64-bit DMG for 2.6.6, then this patch is not required.

> Of course, ActiveState and the other 
> distributors of OS X installers could choose otherwise and, if so, patch 
> it accordingly.  

That's what I am currently inclined to do as we are dropping 10.4/ppc support (in favour of 10.5+/x86_64) in upcoming 2.6 releases.

> My opinion is that there are enough loose ends that it 
> is better to focus on 64-bit support on 2.7/3.2 and on 10.6 (and higher) 
> only.

Ok.

-srid


From nad at acm.org  Sat Aug 14 01:05:10 2010
From: nad at acm.org (Ned Deily)
Date: Fri, 13 Aug 2010 16:05:10 -0700
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
	<nad-36924A.17541212082010@news.gmane.org>
	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>
	<nad-57167D.15365113082010@dough.gmane.org>
	<BA29D3FD-F05A-4042-8F33-B92001959AC4@activestate.com>
Message-ID: <nad-1339BD.16051013082010@dough.gmane.org>

In article <BA29D3FD-F05A-4042-8F33-B92001959AC4 at activestate.com>,
 Sridhar Ratnakumar <sridharr at activestate.com> wrote:
[...]
> That can be said for the Python 2.7 Mac installer too, no? bin/python2.7 is a 
> multi-arch binary, and bin/python symlinks to bin/python2.7.

The 2.7 bin/python2.7 can be overridden with /usr/bin/arch (because of 
those changes to pythonw.c); 2.6 can't.

-- 
 Ned Deily,
 nad at acm.org


From kw at codebykevin.com  Mon Aug 16 15:44:54 2010
From: kw at codebykevin.com (Kevin Walzer)
Date: Mon, 16 Aug 2010 09:44:54 -0400
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <BA29D3FD-F05A-4042-8F33-B92001959AC4@activestate.com>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>	<nad-36924A.17541212082010@news.gmane.org>	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>	<nad-57167D.15365113082010@dough.gmane.org>
	<BA29D3FD-F05A-4042-8F33-B92001959AC4@activestate.com>
Message-ID: <4C6940D6.80401@codebykevin.com>

On 8/13/10 6:54 PM, Sridhar Ratnakumar wrote:

>
>> Of course, ActiveState and the other
>> distributors of OS X installers could choose otherwise and, if so, patch
>> it accordingly.
>
> That's what I am currently inclined to do as we are dropping 10.4/ppc support (in favour of 10.5+/x86_64) in upcoming 2.6 releases.

I haven't followed every item of this thread, so I hope this question 
isn't redundant: will a forthcoming release of ActivePython 2.6 or 2.7 
be built as a 32/64-bit binary for Intel, and will it work with a 
32/64-bit Intel build of ActiveTcl 8.6 beta (based on Cocoa)?

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From sridharr at activestate.com  Mon Aug 16 19:27:27 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Mon, 16 Aug 2010 10:27:27 -0700
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <4C6940D6.80401@codebykevin.com>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>	<nad-36924A.17541212082010@news.gmane.org>	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>	<nad-57167D.15365113082010@dough.gmane.org>
	<BA29D3FD-F05A-4042-8F33-B92001959AC4@activestate.com>
	<4C6940D6.80401@codebykevin.com>
Message-ID: <4AA8E460-B5DB-4989-83CD-82AB21C7052A@activestate.com>


On 2010-08-16, at 6:44 AM, Kevin Walzer wrote:

> On 8/13/10 6:54 PM, Sridhar Ratnakumar wrote:
> 
>> 
>>> Of course, ActiveState and the other
>>> distributors of OS X installers could choose otherwise and, if so, patch
>>> it accordingly.
>> 
>> That's what I am currently inclined to do as we are dropping 10.4/ppc support (in favour of 10.5+/x86_64) in upcoming 2.6 releases.
> 
> I haven't followed every item of this thread, so I hope this question isn't redundant: will a forthcoming release of ActivePython 2.6 or 2.7 be built as a 32/64-bit binary for Intel

ActivePython 2.7 is already built for 32/64-bit intel[1]. Python 2.6.6 will be released today and the subsequent ActivePython 2.6 (scheduled this week) *will* be built for 32/64-bit intel.

> [...] and will it work with a 32/64-bit Intel build of ActiveTcl 8.6 beta (based on Cocoa)?

No, the thing is tkinter is tied to a specific version of tcl/tk ... as it does not use the tcl stubs mechanism,
http://bugs.python.org/issue8798
http://code.activestate.com/lists/python-list/197819/

ActivePython 2.6 and 2.7 are built for Tcl 8.5.  On Snow Leopard, it will work fine with Apple's Tcl/Tk both in i386 and x86_64 mode. On 10.5, you will need an intel build of 8.5 ... otherwise, install ActiveTcl 8.5 (i386) and run Python in 32-bit mode as "arch -i386 python" if you want to use tkinter. Note that Python 2.6 from python.org is still (and will be) an universal binary, and uses tcl 8.4.

An ideal fix to this problem, according to Hobbs, is to patch _tkinter.c to use the tcl stubs mechanism in order to support higher tcl versions during runtime (eg: 8.6).

-srid

[1] http://www.activestate.com/blog/2010/07/activepython-27-released

From kw at codebykevin.com  Mon Aug 16 23:52:04 2010
From: kw at codebykevin.com (Kevin Walzer)
Date: Mon, 16 Aug 2010 17:52:04 -0400
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <4AA8E460-B5DB-4989-83CD-82AB21C7052A@activestate.com>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>	<nad-36924A.17541212082010@news.gmane.org>	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>	<nad-57167D.15365113082010@dough.gmane.org>
	<BA29D3FD-F05A-4042-8F33-B92001959AC4@activestate.com>
	<4C6940D6.80401@codebykevin.com>
	<4AA8E460-B5DB-4989-83CD-82AB21C7052A@activestate.com>
Message-ID: <4C69B304.2040505@codebykevin.com>

On 8/16/10 1:27 PM, Sridhar Ratnakumar wrote:
>
> An ideal fix to this problem, according to Hobbs, is to patch _tkinter.c to use the tcl stubs mechanism in order to support higher tcl versions during runtime (eg: 8.6).
>

I had seen discussion of this; has ActiveState decided not to include 
such a patch in ActivePython?


-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com

From ronaldoussoren at mac.com  Tue Aug 17 12:19:06 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 17 Aug 2010 12:19:06 +0200
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
Message-ID: <20B9C81B-5A51-4C79-815B-C95BB4AF463C@mac.com>


On 12 Aug, 2010, at 22:03, Sridhar Ratnakumar wrote:

> When Python 2.6 is built with --universal-archs=intel, the default Python binary is symlinked to the 32-bit binary:
> 
>  lrwxr-xr-x  1 root  admin     12 10 Aug 15:31 python -> python2.6-32
> 
> Python 2.7, however, is 64-bit by default. Is there a particular reason why this behaviour is different for 2.6 (and 3.1)?

Not really. I was way more conservative when 2.6 was released, and switched to the current behaviour in 2.7 because that made the makefiles easier and libraries have had a long time to transition to 64-bit compatibility.

You can always select the architecture to use using the 'arch' command (which works with 2.7 but not with 2.6 or Apple's python)

Ronald
> 
> -srid
> _______________________________________________
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100817/38a83f8d/attachment.bin>

From ronaldoussoren at mac.com  Tue Aug 17 12:20:46 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 17 Aug 2010 12:20:46 +0200
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
	<nad-36924A.17541212082010@news.gmane.org>
	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>
Message-ID: <C3D47E13-18B6-4508-9F29-27244126D630@mac.com>


On 13 Aug, 2010, at 23:47, Sridhar Ratnakumar wrote:
> 
> 
> But bin/python2.6 itself links to python2.6-32. What about changing that to python2.6-all - thus leaving the choice of arch to OS loader instead of the Python's build system?

This behaviour will not change in the 2.6 branch due to backward compatibility constraints.

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100817/8573622d/attachment.bin>

From ronaldoussoren at mac.com  Tue Aug 17 12:23:43 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 17 Aug 2010 12:23:43 +0200
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <4AA8E460-B5DB-4989-83CD-82AB21C7052A@activestate.com>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>
	<nad-36924A.17541212082010@news.gmane.org>
	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>
	<nad-57167D.15365113082010@dough.gmane.org>
	<BA29D3FD-F05A-4042-8F33-B92001959AC4@activestate.com>
	<4C6940D6.80401@codebykevin.com>
	<4AA8E460-B5DB-4989-83CD-82AB21C7052A@activestate.com>
Message-ID: <551C7566-F1AF-4CC2-A505-47F598673E4B@mac.com>


On 16 Aug, 2010, at 19:27, Sridhar Ratnakumar wrote:
> 
> An ideal fix to this problem, according to Hobbs, is to patch _tkinter.c to use the tcl stubs mechanism in order to support higher tcl versions during runtime (eg: 8.6).

Do you have a patch for that?

The best I can manage is to finally review and merge Kevin's patches to IDLE to make it work properly with Tk 8.5.  I do not have enough time to research how to use the stubs mechanism.

This could definitely get into python 3.2, and I might be able to get both into the next 2.7 and 3.1 releases as well if the changes aren't too invasive.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100817/359b3a3b/attachment.bin>

From massimodisasha at yahoo.it  Wed Aug 18 17:05:15 2010
From: massimodisasha at yahoo.it (Massimo Di Stefano)
Date: Wed, 18 Aug 2010 17:05:15 +0200
Subject: [Pythonmac-SIG] py2applet osx 10.6.4 ('Target' object has no
	attribute 'appdir')
Message-ID: <E2140AC6-F01F-4122-98AF-A7BD550E0339@yahoo.it>

Hello All,

i'm ring to use py2applet to bundle a python application that uses several python mudules (gdal, pyqt, pygame)

as suggested on the web page :

http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html#installing-with-easy-install

i removed the old py2applet and 
i installed  the latest setuptools and py2app

then running :

py2applet --make-setup myapp.py

py2applet myapp.py

i got this error :

/temp/pygame/surflock.py to pygame/surflock.pyc
byte-compiling /private/var/folders/ve/veXy9T8eF2mFKQhl31Blv++++TI/-Tmp-/tmppNGWPG/build/bdist.macosx-10.6-universal/python2.6-semi_standalone/app/temp/pygame/time.py to pygame/time.pyc
byte-compiling /private/var/folders/ve/veXy9T8eF2mFKQhl31Blv++++TI/-Tmp-/tmppNGWPG/build/bdist.macosx-10.6-universal/python2.6-semi_standalone/app/temp/pygame/transform.py to pygame/transform.pyc
*** creating application bundle: PlanetSasha ***
Traceback (most recent call last):
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/build_app.py", line 604, in _run
    self.run_normal()
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/build_app.py", line 675, in run_normal
    self.create_binaries(py_files, pkgdirs, extensions, loader_files)
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/build_app.py", line 772, in create_binaries
    target, arcname, pkgexts, copyexts, target.script)
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/build_app.py", line 1207, in build_executable
    appdir, resdir, plist = self.create_bundle(target, script)
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/build_app.py", line 1130, in create_bundle
    use_runtime_preference=use_runtime_preference
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/build_app.py", line 1119, in create_appbundle
    extension=self.extension,
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/create_appbundle.py", line 34, in create_appbundle
    copy(srcmain, destmain)
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/util.py", line 233, in mergecopy
    return macholib.util.mergecopy(src, dest)
  File "build/bdist.macosx-10.6-universal/egg/macholib/util.py", line 111, in mergecopy
    copy2(src, dest)
  File "build/bdist.macosx-10.6-universal/egg/macholib/util.py", line 43, in copy2
    shutil.copy2(fsencoding(src), fsencoding(dst))
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/shutil.py", line 99, in copy2
    copyfile(src, dst)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/shutil.py", line 52, in copyfile
    fsrc = open(src, 'rb')
IOError: [Errno 2] No such file or directory: '/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/apptemplate/prebuilt/main-i386'
> /System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/shutil.py(52)copyfile()
-> fsrc = open(src, 'rb')
(Pdb) q
Traceback (most recent call last):
  File "/usr/local/bin/py2applet", line 8, in <module>
    load_entry_point('py2app==0.5.2', 'console_scripts', 'py2applet')()
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/script_py2applet.py", line 134, in main
    build(args, scripts, data_files, options)
  File "/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg/py2app/script_py2applet.py", line 187, in build
    target.appdir,
AttributeError: 'Target' object has no attribute 'appdir'



have you any clue on what's wrong and how to fix it ?

thanks,

Massimo.

From a.h.jaffe at gmail.com  Wed Aug 18 18:17:43 2010
From: a.h.jaffe at gmail.com (Andrew Jaffe)
Date: Wed, 18 Aug 2010 17:17:43 +0100
Subject: [Pythonmac-SIG] Python 2.7 OSX install issues: site-packages and
	32/64-bit
Message-ID: <i4h137$f70$1@dough.gmane.org>

Hi all,

I've been trying to move to Python 2.7 on Max OSX 10.6.4, and a few 
issues have arisen.

The first is a changed location of site-packages and its relation to 
directories for setuptools/easyinstall. In recent versions <=2.6, the 
default site-packages was
        ~/Library/Python/2.6/site-packages
but in 2.7, it seems to have moved to
        ~/Library/Python/2.7/lib/python/site-packages/
This mostly bit me when attempting to use setuptools, which [still] 
advises the following line in ~/.pydistutils.cfg
    install_lib = ~/Library/Python/$py_version_short/site-packages
Is the new location canonical from now on? Should we permanently switch 
to that?

The other issue seems to have to do with 32- vs 64-bit libraries, 
especially in my attempts to install matplotlib. This has bit me with 
wxPython, along with the libpng, zlib, and freetype dependencies (which 
have previously been grabbed from fink but which are 32 bit). Are there 
any magical hints for getting this to work (or binary installers which 
include all of these)?

Yours,

Andrew


From hsoft at hardcoded.net  Thu Aug 19 09:44:40 2010
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Thu, 19 Aug 2010 09:44:40 +0200
Subject: [Pythonmac-SIG] I published a couple of improvements to py2app
Message-ID: <AANLkTim=18X=Lqq52Gqwng54SKvcSjX_NH7_-vogyaaQ@mail.gmail.com>

Hi all,

I've been working on a few improvements for py2app. Since Ronald said
he'd bring the repository to mercurial soon, I was waiting, but
managing those patches became too much work so I converted py2app's
SVN repo into a mercurial one and committed my improvements. These
improvements are:

Better py3k support: The "plugin" feature of py2app didn't work at all
under py3k, so I went ahead and did it (thanks to a couple of helpful
tips from Ronald). I also removed dependency on the Carbon module for
the "--alias" option (the Carbon module is not available in py3k).

Sphinx documentation: I converted the old docs to Sphinx.

Option to use the built-in modulefinder instead of modulegraph: I was
getting tired of having to write workaround imports to modulegraph
(which doesn't like relative imports very well, even the latest
version) and I didn't want to dig in modulegraph itself, so as an
experiment, I added a "--use-modulefinder" option to py2app. I haven't
tested it much, but so far, I'm able to build one of my apps *without*
the workarounds I had for modulegraph, so it my case, it works better.

So if you're interested in any of these improvements, the repo is at
http://bitbucket.org/hsoft/py2app . All of these improvements are
applied to the default branch, but still, each of them as its own
branch, so you can pick which you want and apply them to py2app's
trunk.
--
Virgil Dupras

From elguavas at gmail.com  Thu Aug 19 10:25:39 2010
From: elguavas at gmail.com (Stephen Gava)
Date: Thu, 19 Aug 2010 18:25:39 +1000
Subject: [Pythonmac-SIG] I published a couple of improvements to py2app
In-Reply-To: <AANLkTim=18X=Lqq52Gqwng54SKvcSjX_NH7_-vogyaaQ@mail.gmail.com>
References: <AANLkTim=18X=Lqq52Gqwng54SKvcSjX_NH7_-vogyaaQ@mail.gmail.com>
Message-ID: <4C6CEA83.4060903@gmail.com>


thanks a bunch Virgil. ;)

On 19/08/10 5:44 PM, Virgil Dupras wrote:
> Hi all,
>
> I've been working on a few improvements for py2app. Since Ronald said
> he'd bring the repository to mercurial soon, I was waiting, but
> managing those patches became too much work so I converted py2app's
[...]

From ronaldoussoren at mac.com  Thu Aug 19 12:02:58 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Thu, 19 Aug 2010 03:02:58 -0700 (PDT)
Subject: [Pythonmac-SIG] I published a couple of improvements to py2app
In-Reply-To: <AANLkTim=18X=Lqq52Gqwng54SKvcSjX_NH7_-vogyaaQ@mail.gmail.com>
Message-ID: <f1d4badb-3820-6e01-c39c-bb0b455c29ad@me.com>

?
(Sorry about the odd quoting and formatting, mobile me webmail crapped out on me)



On 19 Aug, 2010,at 09:45 AM, Virgil Dupras <hsoft at hardcoded.net> wrote:

Hi all,

I've been working on a few improvements for py2app. Since Ronald said
he'd bring the repository to mercurial soon, I was waiting, but
managing those patches became too much work so

Mercurial patchqueues make managing patches quite easy.

Wrt. converting the py2app repository: real life interfered with my plans. ?I should have some time for this in the weekend, but not before that because I'll be at work until 10pm tonight and need to be back before 9 am in the morning to deal with any fallout from the maintainance we're doing tonight. ? It's unlikely that I'll want to work on py2app tomorrow night because of that.


I converted py2app's
SVN repo into a mercurial one and committed my improvements. These
improvements are:

Better py3k support: The "plugin" feature of py2app didn't work at all
under py3k, so I went ahead and did it (thanks to a couple of helpful
tips from Ronald). I also removed dependency on the Carbon module for
the "--alias" option (the Carbon module is not available in py3k).
?
Those will likely get merged.



Sphinx documentation: I converted the old docs to Sphinx.
?

Likewise.



Option to use the built-in modulefinder instead of modulegraph: I was
getting tired of having to write workaround imports to modulegraph
(which doesn't like relative imports very well, even the latest
version) and I didn't want to dig in modulegraph itself, so as an
experiment, I added a "--use-modulefinder" option to py2app. I haven't
tested it much, but so far, I'm able to build one of my apps *without*
the workarounds I had for modulegraph, so it my case, it works better.
?
This won't get merged, I'd much rather fix modulegraph. If that doesn't work out for some reason modulegraph should get ripped out, choosing between the two is unnecessary complexity for both the maintainers and users of py2app.

One of the things on my todolist for py2app and related modules is to add proper tests, which should make it easier to ensure that bugs get fixed and stay fixed.

And then there are the mac-related bugs in CPython itself, which also need my attention.

Ronald

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100819/70e72348/attachment.html>

From hsoft at hardcoded.net  Thu Aug 19 20:04:13 2010
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Thu, 19 Aug 2010 20:04:13 +0200
Subject: [Pythonmac-SIG] I published a couple of improvements to py2app
In-Reply-To: <f1d4badb-3820-6e01-c39c-bb0b455c29ad@me.com>
References: <AANLkTim=18X=Lqq52Gqwng54SKvcSjX_NH7_-vogyaaQ@mail.gmail.com>
	<f1d4badb-3820-6e01-c39c-bb0b455c29ad@me.com>
Message-ID: <AANLkTimJKo7kORv2oXaRmmfBVOrMbr1adQHjAf1D_f49@mail.gmail.com>

On Thu, Aug 19, 2010 at 12:02 PM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
>
> Option to use the built-in modulefinder instead of modulegraph: I was
> getting tired of having to write workaround imports to modulegraph
> (which doesn't like relative imports very well, even the latest
> version) and I didn't want to dig in modulegraph itself, so as an
> experiment, I added a "--use-modulefinder" option to py2app. I haven't
> tested it much, but so far, I'm able to build one of my apps *without*
> the workarounds I had for modulegraph, so it my case, it works better.
>
>
> This won't get merged, I'd much rather fix modulegraph. If that doesn't work
> out for some reason modulegraph should get ripped out, choosing between the
> two is unnecessary complexity for both the maintainers and users of py2app.
> One of the things on my todolist for py2app and related modules is to add
> proper tests, which should make it easier to ensure that bugs get fixed and
> stay fixed.
> And then there are the mac-related bugs in CPython itself, which also need
> my attention.
> Ronald
>

Sure. I didn't implement this in the hope that it was merged, it was
more of a way to experiment how modulegraph and modulefinder compared
when I ran it on my apps.

Virgil

From ronaldoussoren at mac.com  Fri Aug 20 07:38:16 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 20 Aug 2010 07:38:16 +0200
Subject: [Pythonmac-SIG] I published a couple of improvements to py2app
In-Reply-To: <AANLkTimJKo7kORv2oXaRmmfBVOrMbr1adQHjAf1D_f49@mail.gmail.com>
References: <AANLkTim=18X=Lqq52Gqwng54SKvcSjX_NH7_-vogyaaQ@mail.gmail.com>
	<f1d4badb-3820-6e01-c39c-bb0b455c29ad@me.com>
	<AANLkTimJKo7kORv2oXaRmmfBVOrMbr1adQHjAf1D_f49@mail.gmail.com>
Message-ID: <BFA7E973-9758-45A8-85BB-9804A4B9C4FD@mac.com>


On 19 Aug, 2010, at 20:04, Virgil Dupras wrote:

> On Thu, Aug 19, 2010 at 12:02 PM, Ronald Oussoren
> <ronaldoussoren at mac.com> wrote:
>> 
>> Option to use the built-in modulefinder instead of modulegraph: I was
>> getting tired of having to write workaround imports to modulegraph
>> (which doesn't like relative imports very well, even the latest
>> version) and I didn't want to dig in modulegraph itself, so as an
>> experiment, I added a "--use-modulefinder" option to py2app. I haven't
>> tested it much, but so far, I'm able to build one of my apps *without*
>> the workarounds I had for modulegraph, so it my case, it works better.
>> 
>> 
>> This won't get merged, I'd much rather fix modulegraph. If that doesn't work
>> out for some reason modulegraph should get ripped out, choosing between the
>> two is unnecessary complexity for both the maintainers and users of py2app.
>> One of the things on my todolist for py2app and related modules is to add
>> proper tests, which should make it easier to ensure that bugs get fixed and
>> stay fixed.
>> And then there are the mac-related bugs in CPython itself, which also need
>> my attention.
>> Ronald
>> 
> 
> Sure. I didn't implement this in the hope that it was merged, it was
> more of a way to experiment how modulegraph and modulefinder compared
> when I ran it on my apps.

There is something that would help trying to fix the problem your having with modulegraph: Create simple programs that reproduce the problem(s).

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100820/56b93b6a/attachment.bin>

From hsoft at hardcoded.net  Fri Aug 20 12:44:04 2010
From: hsoft at hardcoded.net (Virgil Dupras)
Date: Fri, 20 Aug 2010 12:44:04 +0200
Subject: [Pythonmac-SIG] I published a couple of improvements to py2app
In-Reply-To: <BFA7E973-9758-45A8-85BB-9804A4B9C4FD@mac.com>
References: <AANLkTim=18X=Lqq52Gqwng54SKvcSjX_NH7_-vogyaaQ@mail.gmail.com>
	<f1d4badb-3820-6e01-c39c-bb0b455c29ad@me.com>
	<AANLkTimJKo7kORv2oXaRmmfBVOrMbr1adQHjAf1D_f49@mail.gmail.com>
	<BFA7E973-9758-45A8-85BB-9804A4B9C4FD@mac.com>
Message-ID: <AANLkTimRkCM7S0fKp-u0=gYJ-GpZ4mj_vQQtZ9nhg=Ou@mail.gmail.com>

On Fri, Aug 20, 2010 at 7:38 AM, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
> On 19 Aug, 2010, at 20:04, Virgil Dupras wrote:
>
>> On Thu, Aug 19, 2010 at 12:02 PM, Ronald Oussoren
>> <ronaldoussoren at mac.com> wrote:
>>>
>>> Option to use the built-in modulefinder instead of modulegraph: I was
>>> getting tired of having to write workaround imports to modulegraph
>>> (which doesn't like relative imports very well, even the latest
>>> version) and I didn't want to dig in modulegraph itself, so as an
>>> experiment, I added a "--use-modulefinder" option to py2app. I haven't
>>> tested it much, but so far, I'm able to build one of my apps *without*
>>> the workarounds I had for modulegraph, so it my case, it works better.
>>>
>>>
>>> This won't get merged, I'd much rather fix modulegraph. If that doesn't work
>>> out for some reason modulegraph should get ripped out, choosing between the
>>> two is unnecessary complexity for both the maintainers and users of py2app.
>>> One of the things on my todolist for py2app and related modules is to add
>>> proper tests, which should make it easier to ensure that bugs get fixed and
>>> stay fixed.
>>> And then there are the mac-related bugs in CPython itself, which also need
>>> my attention.
>>> Ronald
>>>
>>
>> Sure. I didn't implement this in the hope that it was merged, it was
>> more of a way to experiment how modulegraph and modulefinder compared
>> when I ran it on my apps.
>
> There is something that would help trying to fix the problem your having with modulegraph: Create simple programs that reproduce the problem(s).
>
> Ronald
>
>

I reproduced the problem and created a package reproducing it. I
thought it would be hard, but it's really easy: I have a main script
and a package 'pkg' containing submodules 'a' and 'b'. 'b' does
nothing, 'a' import 'b' with 'from . import b'. the mainscript does
'from pkg import a'. Modulefinder finds both 'a' and 'b'. Modulegraph
only finds 'a'. I included a 'run.py' script in the package that runs
them both and print the report:

MODULEFINDER

  Name                      File
  ----                      ----
m __main__                  main_script.py
P pkg
/Users/hsoft/Desktop/modulegraph_test/pkg/__init__.py
m pkg.a                     /Users/hsoft/Desktop/modulegraph_test/pkg/a.py
m pkg.b                     /Users/hsoft/Desktop/modulegraph_test/pkg/b.py
MODULEGRAPH

Class           Name                      File
----            ----                      ----
Script          main_script.py
/Users/hsoft/Desktop/modulegraph_test/main_script.py
Package         pkg
/Users/hsoft/Desktop/modulegraph_test/pkg/__init__.py
SourceModule    pkg.a

Regards,
Virgil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: modulegraph_test.zip
Type: application/zip
Size: 2982 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100820/0c87387c/attachment.zip>

From cweisiger at msg.ucsf.edu  Fri Aug 20 23:48:10 2010
From: cweisiger at msg.ucsf.edu (Chris Weisiger)
Date: Fri, 20 Aug 2010 14:48:10 -0700
Subject: [Pythonmac-SIG] [py2app] No module named os
Message-ID: <AANLkTi=6QXjXv0X2nY-A5S_DVSmwKQ8K2N13Ufq6K5Ga@mail.gmail.com>

I'm trying to use py2app to generate a standalone executable of a program
I've made (major dependencies: wx, OpenGL, numpy/scipy). I've done this
successfully several months ago, as evidenced by horribly out-of-date
versions of the program that my users are still using because I can't get a
newer version to work on their systems! I remember getting the thing working
to be a bit of a chore, but unfortunately I didn't take notes on what all I
did. Presumably the apps generated by py2app should not be dependent on
changes that my users have made to their own systems.

Doing "python setup.py py2app" apparently works, generating dist/editor.app
which runs fine on my own computer. However, when run on a computer that is
not my computer, I get the error "no module named os" and the program exits.
Specifically, here's the complete error log from Console.app:

8/20/10 2:26:59 PM [0x0-0x1ad1ad].org.pythonmac.unspecified.editor[12219]
'import site' failed; use -v for traceback
8/20/10 2:26:59 PM [0x0-0x1ad1ad].org.pythonmac.unspecified.editor[12219]
Traceback (most recent call last):
8/20/10 2:26:59 PM [0x0-0x1ad1ad].org.pythonmac.unspecified.editor[12219]
File "/Volumes/KINGSTON/editor.app/Contents/Resources/__boot__.py", line 4,
in <module>
8/20/10 2:26:59 PM
[0x0-0x1ad1ad].org.pythonmac.unspecified.editor[12219]     _chdir_resource()

8/20/10 2:26:59 PM [0x0-0x1ad1ad].org.pythonmac.unspecified.editor[12219]
File "/Volumes/KINGSTON/editor.app/Contents/Resources/__boot__.py", line 2,
in _chdir_resource
8/20/10 2:26:59 PM
[0x0-0x1ad1ad].org.pythonmac.unspecified.editor[12219]     import os
8/20/10 2:26:59 PM [0x0-0x1ad1ad].org.pythonmac.unspecified.editor[12219]
ImportError: No module named os
8/20/10 2:26:59 PM editor[12219] editor Error

(Incidentally, this used to complain about being unable to import traceback,
until I turned off argv emulation)

Some Googling suggested that I try unsetting environment variables at the
start of my script as they might be interfering. So I added this to the top
of my script:

import os
for key in ['PYTHONPATH', 'PYTHONHOME', 'PYTHONEXECUTABLE']:
    if key in os.environ:
        del os.environ[key]

No dice. I tried manually inserting that same code into the top of
__boot__.py; the only difference then is that it crashes at that "import os"
invocation instead of the normal one.

I thought maybe that I was using the wrong version of Python -- I know
there's some annoying weirdness with py2app refusing to use the standard
Python install. I have /usr/bin/python2.5, /usr/local/bin/python2.5 (the
official install?), and /opt/local/bin/python2.5. The first one generates
apps successfully, the second barfs because it can't find main-i386 even
when I symlink main-fat3 to it, and the last doesn't have setuptools and
therefore is presumably not the one I've used in the past. I haven't changed
dependencies for the app itself since I last made a working app, and I know
that it wasn't a Python 2.6 app.

My setup.py script is as follows:

from setuptools import setup

APP = ['editor.py']
DATA_FILES = ['Priithon']
OPTIONS = {}

setup(
    app=APP,
    data_files=DATA_FILES,
    options={'py2app': OPTIONS},
    setup_requires=['py2app'],
)

Any advice? Suggestions? I've run out of  ideas myself.

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100820/cb557328/attachment.html>

From dan at rosspixelworks.com  Sat Aug 21 15:12:26 2010
From: dan at rosspixelworks.com (Dan Ross)
Date: Sat, 21 Aug 2010 08:12:26 -0500
Subject: [Pythonmac-SIG] [py2app] No module named os
Message-ID: <4C6FD0BA.8080702@rosspixelworks.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100821/ca4c7872/attachment.html>

From ygor at comcast.net  Sat Aug 21 18:52:36 2010
From: ygor at comcast.net (Dan White)
Date: Sat, 21 Aug 2010 12:52:36 -0400
Subject: [Pythonmac-SIG] A script for Scribus that won't run on my Mac
Message-ID: <EE4ED661-BFB5-4B17-9425-DA745726E132@comcast.net>

I am a python n00b, and I cannot figure this out.

I got a script from forum that is supposed to "build" a set of  
calendar pages in Scribus.

It won't run on my Mac (Intel iMac, MacOS 10.5.8, Python 2.7, Scribus  
1.3.8)

Here is an extract containing the offending code:

---------------------------------------------
def drawRulesGrid(pageSide):
	"""Draws rules on the page"""
	lineSpace = (LINE_LAST_Y - LINE_FIRST_Y) / 30
	if pageSide == 'right':
		StartLines = (R_LINE_X + (C * LINE_X_OFFSET) for C in range(COLUMNS))
		BigLines = [0, 10, 20, 25, 30]
	elif pageSide == 'left':
		StartLines = (L_LINE_X + (C * LINE_X_OFFSET) for C in range(COLUMNS))
		BigLines = [0, 10, 20, 30]
	for j in StartLines:
		StartLineX, StartLineY = j, LINE_FIRST_Y
		for i in range(31):
			Line = createLine(StartLineX, StartLineY, StartLineX+LINE_LENGHT,  
StartLineY)
			if i in BigLines:
				setLineWidth(BIG_LINE_WIDTH, Line)
			else:
				setLineWidth(THIN_LINE_WIDTH, Line)
			StartLineY += lineSpace
---------------------------------------------

And the error:

---------------------------------------------
Traceback (most recent call last):
File "", line 8, in ?
File "SamAgenda.py", line 221
    StartLines = (R_LINE_X + (C * LINE_X_OFFSET) for C in  
range(COLUMNS))
                                                   ^
SyntaxError: invalid syntax
---------------------------------------------

In case the spacing gets messed up, the caret is pointing at the "r"  
in "for"

The author claims this runs on python 2.6.5, Scribus 1.3.3.13svn,  
Ubuntu 10.04.

Any clues for this clueless one ?
Thanks.

From jeffh at activestate.com  Mon Aug 16 23:54:34 2010
From: jeffh at activestate.com (Jeff Hobbs)
Date: Mon, 16 Aug 2010 14:54:34 -0700
Subject: [Pythonmac-SIG] Python 2.6/3.1 on Mac - default arch is i386?
In-Reply-To: <4C69B304.2040505@codebykevin.com>
References: <84CB970D-35A3-45EA-9B5C-5A1DA09DD8CD@activestate.com>	<nad-36924A.17541212082010@news.gmane.org>	<78D65BDB-AB9C-4E8D-9440-4D071D3D8680@activestate.com>	<nad-57167D.15365113082010@dough.gmane.org>
	<BA29D3FD-F05A-4042-8F33-B92001959AC4@activestate.com>
	<4C6940D6.80401@codebykevin.com>
	<4AA8E460-B5DB-4989-83CD-82AB21C7052A@activestate.com>
	<4C69B304.2040505@codebykevin.com>
Message-ID: <4C69B39A.3070308@activestate.com>

On 16/08/2010 2:52 PM, Kevin Walzer wrote:
> On 8/16/10 1:27 PM, Sridhar Ratnakumar wrote:
>>
>> An ideal fix to this problem, according to Hobbs, is to patch
>> _tkinter.c to use the tcl stubs mechanism in order to support higher
>> tcl versions during runtime (eg: 8.6).
>>
>
> I had seen discussion of this; has ActiveState decided not to include
> such a patch in ActivePython?

I've done some initial work on that patch, but it isn't complete.  Every 
time I look at the code, I have to fight the urge to rewrite more than 
is necessary.

Jeff

From ronaldoussoren at mac.com  Sun Aug 22 14:32:47 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 22 Aug 2010 14:32:47 +0200
Subject: [Pythonmac-SIG] py2app and related packages on bitbucket
Message-ID: <7FA1B5CD-4CE1-411F-B7E0-4B82F83041F2@mac.com>

Hi,

I've converted the repositories for py2app and related packages to mercurial and posted them on bitbucket. The new home pages are:

py2app: http://bitbucket.org/ronaldoussoren/py2app
macholib: http://bitbucket.org/ronaldoussoren/macholib
modulegraph: http://bitbucket.org/ronaldoussoren/modulegraph
altgraph: http://bitbucket.org/ronaldoussoren/altgraph

I have disabled the wiki for now, but did enable the issue tracker.

The pyobjc repository will also be converted to mercurial, but that's a more complicated process due to the more complicated history in that repository.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100822/7d2bcc3c/attachment.bin>

From ronaldoussoren at mac.com  Sun Aug 22 17:14:51 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Sun, 22 Aug 2010 17:14:51 +0200
Subject: [Pythonmac-SIG] I published a couple of improvements to py2app
In-Reply-To: <AANLkTimRkCM7S0fKp-u0=gYJ-GpZ4mj_vQQtZ9nhg=Ou@mail.gmail.com>
References: <AANLkTim=18X=Lqq52Gqwng54SKvcSjX_NH7_-vogyaaQ@mail.gmail.com>
	<f1d4badb-3820-6e01-c39c-bb0b455c29ad@me.com>
	<AANLkTimJKo7kORv2oXaRmmfBVOrMbr1adQHjAf1D_f49@mail.gmail.com>
	<BFA7E973-9758-45A8-85BB-9804A4B9C4FD@mac.com>
	<AANLkTimRkCM7S0fKp-u0=gYJ-GpZ4mj_vQQtZ9nhg=Ou@mail.gmail.com>
Message-ID: <E15A3210-B469-4D82-B9DC-C8855DD373F1@mac.com>


On 20 Aug, 2010, at 12:44, Virgil Dupras wrote:
> 
> I reproduced the problem and created a package reproducing it. I
> thought it would be hard, but it's really easy: I have a main script
> and a package 'pkg' containing submodules 'a' and 'b'. 'b' does
> nothing, 'a' import 'b' with 'from . import b'. the mainscript does
> 'from pkg import a'. Modulefinder finds both 'a' and 'b'. Modulegraph
> only finds 'a'. I included a 'run.py' script in the package that runs
> them both and print the report:

I've committed a fix for this to the mercurial repo, including a testcase based on your example.

Thanks for finding a simple way to reproduce the problem,

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100822/f9d4f701/attachment.bin>

From ygor at comcast.net  Sun Aug 22 18:21:53 2010
From: ygor at comcast.net (Dan White)
Date: Sun, 22 Aug 2010 12:21:53 -0400
Subject: [Pythonmac-SIG] How do you tell the system which version to use ?
Message-ID: <8D98D3F1-957A-495A-B445-0E6E9D68889F@comcast.net>

I find that I have at least 3 versions of Python on my system.

2 under /System/Library/Frameworks/Python.framework/Versions (2.3 and  
2.5) and one under /Library/Frameworks/Python.framework/Versions (2.7)

Going from Terminal, I get 2.7
Running a script in Scribus, I get 2.3

I found info that says the /System/Library/Frameworks are part of the  
OS installation and that it should not be messed with.

OK.  But how do I get everything to use 2.7 ?

Thanks.

From aahz at pythoncraft.com  Sun Aug 22 18:38:24 2010
From: aahz at pythoncraft.com (Aahz)
Date: Sun, 22 Aug 2010 09:38:24 -0700
Subject: [Pythonmac-SIG] A script for Scribus that won't run on my Mac
In-Reply-To: <EE4ED661-BFB5-4B17-9425-DA745726E132@comcast.net>
References: <EE4ED661-BFB5-4B17-9425-DA745726E132@comcast.net>
Message-ID: <20100822163824.GB11880@panix.com>

On Sat, Aug 21, 2010, Dan White wrote:
>
> def drawRulesGrid(pageSide):
> 	"""Draws rules on the page"""
> 	lineSpace = (LINE_LAST_Y - LINE_FIRST_Y) / 30
> 	if pageSide == 'right':
> 		StartLines = (R_LINE_X + (C * LINE_X_OFFSET) for C in range(COLUMNS))
> 		BigLines = [0, 10, 20, 25, 30]
> 	elif pageSide == 'left':
> 		StartLines = (L_LINE_X + (C * LINE_X_OFFSET) for C in range(COLUMNS))
> 		BigLines = [0, 10, 20, 30]
> 	for j in StartLines:
> 		StartLineX, StartLineY = j, LINE_FIRST_Y
> 		for i in range(31):
> 			Line = createLine(StartLineX, StartLineY, StartLineX+LINE_LENGHT,  
> StartLineY)
> 			if i in BigLines:
> 				setLineWidth(BIG_LINE_WIDTH, Line)
> 			else:
> 				setLineWidth(THIN_LINE_WIDTH, Line)
> 			StartLineY += lineSpace
>
> ---------------------------------------------
> Traceback (most recent call last):
> File "", line 8, in ?
> File "SamAgenda.py", line 221
>    StartLines = (R_LINE_X + (C * LINE_X_OFFSET) for C in range(COLUMNS))
>                                                   ^
> SyntaxError: invalid syntax

Based on your later message, you presumably figured out that this was
not, in fact, Python 2.7 as claimed.  Just posting this for future
reference.
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"...if I were on life-support, I'd rather have it run by a Gameboy than a
Windows box."  --Cliff Wells

From Chris.Barker at noaa.gov  Sun Aug 22 21:31:48 2010
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Sun, 22 Aug 2010 12:31:48 -0700
Subject: [Pythonmac-SIG] How do you tell the system which version to use
	?
In-Reply-To: <8D98D3F1-957A-495A-B445-0E6E9D68889F@comcast.net>
References: <8D98D3F1-957A-495A-B445-0E6E9D68889F@comcast.net>
Message-ID: <4C717B24.1030702@noaa.gov>

Dan White wrote:
> I find that I have at least 3 versions of Python on my system.
> 
> 2 under /System/Library/Frameworks/Python.framework/Versions (2.3 and 
> 2.5) and one under /Library/Frameworks/Python.framework/Versions (2.7)
> 
> Going from Terminal, I get 2.7
> Running a script in Scribus, I get 2.3
> 
> I found info that says the /System/Library/Frameworks are part of the OS 
> installation and that it should not be messed with.
> 
> OK.  But how do I get everything to use 2.7 ?

you probably can't with one way !

using the Terminal, which is used depends on your $PATH variable, which 
is set up in your .bash_profile file, which I think gets auto-modified 
by the python installer.

As for Scribus, you'll have to look at the Scribus docs to see how you 
can set which interpreter it uses.

I don't know anything about Python in Scribus, but off the top of my 
head, I'd expect that which version of python it used would be set at 
build time. Python 2.3 was delivered with OS-X 10.4 -- perhaps your 
scribus binary was set up to use that?

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From cweisiger at msg.ucsf.edu  Mon Aug 23 17:18:01 2010
From: cweisiger at msg.ucsf.edu (Chris Weisiger)
Date: Mon, 23 Aug 2010 08:18:01 -0700
Subject: [Pythonmac-SIG] [py2app] No module named os
In-Reply-To: <4C6FD0BA.8080702@rosspixelworks.com>
References: <4C6FD0BA.8080702@rosspixelworks.com>
Message-ID: <AANLkTikU8Ege8YvKfi6WC4R=vgpbJVL5DXfi3mNtAhb-@mail.gmail.com>

I've put the program online here:

http://derakon.dyndns.org/~chriswei/temp2/editor.tgz

When run, it should show a large blank window with four icons in the
upper-left corner.

Thanks for being willing to take a look.

-Chris

On Sat, Aug 21, 2010 at 6:12 AM, Dan Ross <dan at rosspixelworks.com> wrote:

>  Hey Chris-
>
> Is the source available anywhere? I've made a few wx apps and that sounds
> familiar.
>
> Dan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100823/3759d351/attachment.html>

From dan at rosspixelworks.com  Tue Aug 24 00:26:44 2010
From: dan at rosspixelworks.com (Dan Ross)
Date: Mon, 23 Aug 2010 17:26:44 -0500
Subject: [Pythonmac-SIG] [py2app] No module named os
In-Reply-To: <AANLkTikU8Ege8YvKfi6WC4R=vgpbJVL5DXfi3mNtAhb-@mail.gmail.com>
References: <4C6FD0BA.8080702@rosspixelworks.com>
	<AANLkTikU8Ege8YvKfi6WC4R=vgpbJVL5DXfi3mNtAhb-@mail.gmail.com>
Message-ID: <4C72F5A4.3040708@rosspixelworks.com>

An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100823/a8516c42/attachment.html>

From cweisiger at msg.ucsf.edu  Tue Aug 24 00:39:17 2010
From: cweisiger at msg.ucsf.edu (Chris Weisiger)
Date: Mon, 23 Aug 2010 15:39:17 -0700
Subject: [Pythonmac-SIG] [py2app] No module named os
In-Reply-To: <4C72F5A4.3040708@rosspixelworks.com>
References: <4C6FD0BA.8080702@rosspixelworks.com>
	<AANLkTikU8Ege8YvKfi6WC4R=vgpbJVL5DXfi3mNtAhb-@mail.gmail.com>
	<4C72F5A4.3040708@rosspixelworks.com>
Message-ID: <AANLkTikgafDeSdWp7J3oE-bbe2y3JG=8qRXO7Ru7Szkt@mail.gmail.com>

That's odd. I get the "couldn't load module(s): P" but Y loads fine. These
are legacy modules from a previous developer, and I generally try to avoid
dealing with them. "Y" refers to either "usefulX.py" or "usefulX2.py", I'm
not certain which. Both are in the Priithon directory. (Note that they
aren't imported as "X" because that's the letter used for one of the modules
the original developer named after himself...fortunately not in this
particular program)

However, I was able to get a standalone version working. I started poking at
the __boot__.py and site.py files in the generated app, and somehow that
made the failures to import fundamental libraries like os and traceback go
away. My only guess is that maybe py2app was including the .pyc files that
had been generated on my local computer? Anyway, after that I got failures
to import numpy.Tester, which are I think due to a version mismatch on my
end. Easily fixed, though, as that module's not actually needed; I just
commented out the imports.

Thanks for being willing to take a look! I think maybe I just needed a
weekend of not thinking about it so I could come back to the problem fresh.
:)

-Chris

On Mon, Aug 23, 2010 at 3:26 PM, Dan Ross <dan at rosspixelworks.com> wrote:

>  Hmmm.....
>
> I'm getting this when I try to run it from Terminal:
>
> dan-rosss-macbook-pro:editor dan$ python editor.py
>  * couldn't load module(s):    Y  P
>
> Traceback (most recent call last):
>   File "editor.py", line 7, in <module>
>     import mainapp
>   File "/Users/dan/Desktop/editor/mainapp.py", line 2, in <module>
>     import demoframe
>   File "/Users/dan/Desktop/editor/demoframe.py", line 6, in <module>
>     import imeditpanel
>   File "/Users/dan/Desktop/editor/imeditpanel.py", line 12, in <module>
>     import realign
>   File "/Users/dan/Desktop/editor/realign.py", line 8, in <module>
>     from Priithon.all import F, Y
> ImportError: cannot import name Y
>
>
> Can you tell me what's supposed to be happening?
>
> On 8/23/10 10:18 AM, Chris Weisiger wrote:
>
> I've put the program online here:
>
> http://derakon.dyndns.org/~chriswei/temp2/editor.tgz<http://derakon.dyndns.org/%7Echriswei/temp2/editor.tgz>
>
> When run, it should show a large blank window with four icons in the
> upper-left corner.
>
> Thanks for being willing to take a look.
>
> -Chris
>
> On Sat, Aug 21, 2010 at 6:12 AM, Dan Ross <dan at rosspixelworks.com> wrote:
>
>>  Hey Chris-
>>
>> Is the source available anywhere? I've made a few wx apps and that sounds
>> familiar.
>>
>> Dan
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100823/8daea1e3/attachment.html>

From dan at rosspixelworks.com  Tue Aug 24 01:55:30 2010
From: dan at rosspixelworks.com (Dan Ross)
Date: Mon, 23 Aug 2010 18:55:30 -0500
Subject: [Pythonmac-SIG] [py2app] No module named os
In-Reply-To: <AANLkTikgafDeSdWp7J3oE-bbe2y3JG=8qRXO7Ru7Szkt@mail.gmail.com>
References: <4C6FD0BA.8080702@rosspixelworks.com>
	<AANLkTikU8Ege8YvKfi6WC4R=vgpbJVL5DXfi3mNtAhb-@mail.gmail.com>
	<4C72F5A4.3040708@rosspixelworks.com>
	<AANLkTikgafDeSdWp7J3oE-bbe2y3JG=8qRXO7Ru7Szkt@mail.gmail.com>
Message-ID: <0b54659f2d8ad56ba20b6c011fcee9ad@rosspixelworks.com>



Happy to try. 

Glad you got it sorted out. 

On Mon, 23 Aug 2010
15:39:17 -0700, Chris Weisiger  wrote:  

That's odd. I get the "couldn't
load module(s): P" but Y loads fine. These are legacy modules from a
previous developer, and I generally try to avoid dealing with them. "Y"
refers to either "usefulX.py" or "usefulX2.py", I'm not certain which. Both
are in the Priithon directory. (Note that they aren't imported as "X"
because that's the letter used for one of the modules the original
developer named after himself...fortunately not in this particular
program)

However, I was able to get a standalone version working. I
started poking at the __boot__.py and site.py files in the generated app,
and somehow that made the failures to import fundamental libraries like os
and traceback go away. My only guess is that maybe py2app was including the
.pyc files that had been generated on my local computer? Anyway, after that
I got failures to import numpy.Tester, which are I think due to a version
mismatch on my end. Easily fixed, though, as that module's not actually
needed; I just commented out the imports. 

Thanks for being willing to
take a look! I think maybe I just needed a weekend of not thinking about it
so I could come back to the problem fresh. :)

-Chris

 On Mon, Aug 23,
2010 at 3:26 PM, Dan Ross  wrote:
  Hmmm.....

 I'm getting this when I try
to run it from Terminal:

 dan-rosss-macbook-pro:editor dan$ python
editor.py
 * couldn't load module(s): Y P 
 Traceback (most recent call
last): File "editor.py", line 7, in 
 import mainapp
 File
"/Users/dan/Desktop/editor/mainapp.py", line 2, in 
 import demoframe
 File
"/Users/dan/Desktop/editor/demoframe.py", line 6, in 
 import imeditpanel

File "/Users/dan/Desktop/editor/imeditpanel.py", line 12, in 
 import
realign
 File "/Users/dan/Desktop/editor/realign.py", line 8, in 
 from
Priithon.all import F, Y
 ImportError: cannot import name Y

 Can you tell
me what's supposed to be happening?

 On 8/23/10 10:18 AM, Chris Weisiger
wrote: I've put the program online
here:

http://derakon.dyndns.org/~chriswei/temp2/editor.tgz [2]

 When run,
it should show a large blank window with four icons in the upper-left
corner. 

 Thanks for being willing to take a look.

 -Chris

 On Sat, Aug
21, 2010 at 6:12 AM, Dan Ross  wrote:
  Hey Chris-

 Is the source
available anywhere? I've made a few wx apps and that sounds familiar.


Dan

 

Links:
------
[1] mailto:dan at rosspixelworks.com
[2]
http://derakon.dyndns.org/%7Echriswei/temp2/editor.tgz
[3]
mailto:dan at rosspixelworks.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100823/f0183768/attachment-0001.html>

From sridharr at activestate.com  Sat Aug 28 01:26:45 2010
From: sridharr at activestate.com (Sridhar Ratnakumar)
Date: Fri, 27 Aug 2010 16:26:45 -0700
Subject: [Pythonmac-SIG] Fwd: ANN: ActivePython 2.6.6.15 is now available
Message-ID: <4C7849B5.7090308@activestate.com>

FYI - ActivePython-2.6 on Mac now supports 64-bit (dropping ppc) and 
requires MacOSX 10.5+.

Like python.org's build, by default Python launches in 32-bit mode 
unless you invoked the `python2.6-64` binary.

-srid

-------- Original Message --------
Subject: ANN: ActivePython 2.6.6.15 is now available
Date: Fri, 27 Aug 2010 16:24:36 -0700
From: Sridhar Ratnakumar <sridharr at activestate.com>
Reply-To: python-list at python.org, activepython-feedback at activestate.com
Organization: ActiveState
To: python-announce-list at python.org, python-list at python.org

ActiveState is pleased to announce ActivePython 2.6.6.15, a complete,
ready-to-install binary distribution of Python 2.6.6.

     http://www.activestate.com/activepython

What's New in ActivePython-2.6.6.15
===================================

*Release date: 25-Aug-2010*

New Features & Upgrades
-----------------------

- Upgrade to Python 2.6.6 (`release notes
<http://www.python.org/download/releases/2.6.6/NEWS.txt>`__)
- Security upgrade to openssl-0.9.8o
- [MacOSX] 64-bit support (PPC and 10.4 are no longer supported)
- Upgrade to PyPM 1.1.1; noteworthy changes:

   - Custom config file support w/ new repository settings (-R free,be
instead of
     -L)
   - Support for installing a local package, eg: ``pypm install
     /path/to/foo.pypm``
   - Bug #87687: Prevent partial downloading of repo index cache

- Upgraded the following packages:

   - Distribute-0.6.14
   - pip-0.8
   - SQLAlchemy-0.6.3

Noteworthy Changes & Bug Fixes
------------------------------

- [MacOSX] Fix Help index on Snow Leopard (10.6) - Bug #87290
- [Windows] Add file extension to Tools\scripts\2to3.py - Bug #87465


What's New in ActivePython-2.6.5.14
===================================

*Release date: 07-Jul-2010*

New Features & Upgrades
-----------------------

- Upgrade to PyPM 1.0.2

   - 'pypm search' now also shows if a package is installed and upgradeable
   - 'pypm info' now prints a concise representation by default
   - 'pypm list --short' will show only packages names; for scripting
purposes
   - Respect distutils install schemes (purelib, scripts)


Noteworthy Changes & Bug Fixes
------------------------------

- [MacOSX] Fix /usr/local/bin symlinks to not use the 'Current' symlink
- [MacOSX] Fix uninstall on Snow Leopard (10.6)
- [Windows] Include IDLE in the Start Menu shortcut, instead of PythonWin


See the release notes for full details:

     http://docs.activestate.com/activepython/2.6/relnotes.html#changes


What is ActivePython?
=====================

ActivePython is ActiveState's binary distribution of Python. Builds for
Windows, Mac OS X, Linux are made freely available. Solaris, HP-UX and
AIX builds, and access to older versions are available in ActivePython
Business, Enterprise and OEM editions:

     http://www.activestate.com/python

ActivePython includes the Python core and the many core extensions: zlib
and bzip2 for data compression, the Berkeley DB (bsddb) and SQLite
(sqlite3) database libraries, OpenSSL bindings for HTTPS support, the
Tix GUI widgets for Tkinter, ElementTree for XML processing, ctypes (on
supported platforms) for low-level library access, and others. The
Windows distribution ships with PyWin32 -- a suite of Windows tools
developed by Mark Hammond, including bindings to the Win32 API and
Windows COM.

ActivePython 2.6 and 2.7 also include a binary package manager for
Python (PyPM) that can be used to install packages much easily. For example:

   C:\>pypm install mysql-python
   [...]

   C:\>python
   >>> import MySQLdb
   >>>

See this page for full details:

     http://docs.activestate.com/activepython/2.6/whatsincluded.html

As well, ActivePython ships with a wealth of documentation for both new
and experienced Python programmers. In addition to the core Python docs,
ActivePython includes the "What's New in Python" series, "Dive into
Python", the Python FAQs & HOWTOs, and the Python Enhancement Proposals
(PEPs).

An online version of the docs can be found here:

     http://docs.activestate.com/activepython/2.6/

We would welcome any and all feedback to:

     activepython-feedback at activestate.com

Please file bugs against ActivePython at:

     http://bugs.activestate.com/enter_bug.cgi?product=ActivePython

Supported Platforms
===================

ActivePython is available for the following platforms:

- Windows/x86   (32-bit)
- Windows/x64   (64-bit) (aka "AMD64")
- Mac OS X
- Linux/x86     (32-bit)
- Linux/x86_64  (64-bit) (aka "AMD64")

- Solaris/SPARC (32-bit and 64-bit) (Business, Enterprise or OEM edition
only)
- Solaris/x86   (32-bit)            (Business, Enterprise or OEM edition
only)
- HP-UX/PA-RISC (32-bit)            (Business, Enterprise or OEM edition
only)
- HP-UX/IA-64   (32-bit and 64-bit) (Enterprise or OEM edition only)
- AIX/PowerPC   (32-bit and 64-bit) (Business, Enterprise or OEM edition
only)

More information about the Business Edition can be found here:

     http://www.activestate.com/business-edition

Custom builds are available in the Enterprise Edition:

     http://www.activestate.com/enterprise-edition

Thanks, and enjoy!

The Python Team

--
Sridhar Ratnakumar
sridharr at activestate.com

From memilanuk at gmail.com  Sat Aug 28 04:55:25 2010
From: memilanuk at gmail.com (Monte Milanuk)
Date: Fri, 27 Aug 2010 19:55:25 -0700
Subject: [Pythonmac-SIG] 'Cleaning house' - getting back to just Apple's
	Python
Message-ID: <i59tqt$g55$1@dough.gmane.org>

Hello all,

I have an older Intel Macbook (circa early 2007) that I have upgraded 
the hardware and software a bit on over the last few months.  Currently 
it is running Snow Leopard 10.6.4, with an install of Python 2.6.5.

Over the course of time, between various upgrades, removing this, 
reinstalling that, etc. etc. I think I've made somewhat of a mess of my 
Python install and I'd like to clean house and get back to just the 
version that shipped with 10.6.x.  No extras or add-ons.  Once I get 
that kind of under control, then maybe see about upgrading/ or having 
multiple versions installed, etc.

1st question...  What is the default version of Python that shipped with 
10.6 Snow Leopard?  I have a Python 2.6.5 install in my Applications 
directory, and I can't recall if I put that there or if that came with 
the new OS (I happened to do the OS upgrade around that time frame...). 
  When I look under /Library/Frameworks/Python.framework/Versions I see 
the following:


macbook:~ monte$ ls -al /Library/Frameworks/Python.framework/Versions/
total 8
drwxr-xr-x   5 root  admin  170 Mar 23 17:46 .
drwxr-xr-x   6 root  admin  204 Mar 23 17:17 ..
drwxrwxr-x  11 root  admin  374 May 12 22:04 2.6
drwxrwxr-x   9 root  admin  306 Aug 24  2009 3.1
lrwxr-xr-x   1 root  admin    3 May  7 16:31 Current -> 2.6
macbook:~ monte$

If I remove the Python 2.6.5 install from the Applications directory, is 
that going to affect things here, or is this a separate (OEM) install?

Sometime in the recent past I remember installing, and then uninstalling 
Python 3.x... so if I remove the 3.1 directory sub-tree, will that clean 
out that bit so I can start over fresh?

Sorry 'bout the confusion.

Monte


From nad at acm.org  Sat Aug 28 09:31:46 2010
From: nad at acm.org (Ned Deily)
Date: Sat, 28 Aug 2010 00:31:46 -0700
Subject: [Pythonmac-SIG] 'Cleaning house' - getting back to just Apple's
	Python
References: <i59tqt$g55$1@dough.gmane.org>
Message-ID: <nad-D56D56.00314628082010@news.gmane.org>

In article <i59tqt$g55$1 at dough.gmane.org>,
 Monte Milanuk <memilanuk at gmail.com> wrote:
> I have an older Intel Macbook (circa early 2007) that I have upgraded 
> the hardware and software a bit on over the last few months.  Currently 
> it is running Snow Leopard 10.6.4, with an install of Python 2.6.5.
> 
> Over the course of time, between various upgrades, removing this, 
> reinstalling that, etc. etc. I think I've made somewhat of a mess of my 
> Python install and I'd like to clean house and get back to just the 
> version that shipped with 10.6.x.  No extras or add-ons.  Once I get 
> that kind of under control, then maybe see about upgrading/ or having 
> multiple versions installed, etc.
> 
> 1st question...  What is the default version of Python that shipped with 
> 10.6 Snow Leopard?  I have a Python 2.6.5 install in my Applications 
> directory, and I can't recall if I put that there or if that came with 
> the new OS (I happened to do the OS upgrade around that time frame...).

The Apple-supplied Pythons in 10.6 are 2.6.1 and 2.5.4.  They are 
invoked with /usr/bin/python2.6 (also /usr/bin/python) and 
/usr/bin/python2.5.  The Python Frameworks are in /System/Library.  
Don't try to remove any of this!

>   When I look under /Library/Frameworks/Python.framework/Versions I see 
> the following:
> 
> 
> macbook:~ monte$ ls -al /Library/Frameworks/Python.framework/Versions/
> total 8
> drwxr-xr-x   5 root  admin  170 Mar 23 17:46 .
> drwxr-xr-x   6 root  admin  204 Mar 23 17:17 ..
> drwxrwxr-x  11 root  admin  374 May 12 22:04 2.6
> drwxrwxr-x   9 root  admin  306 Aug 24  2009 3.1
> lrwxr-xr-x   1 root  admin    3 May  7 16:31 Current -> 2.6
> macbook:~ monte$
> 
> If I remove the Python 2.6.5 install from the Applications directory, is 
> that going to affect things here, or is this a separate (OEM) install?

The python.org installer installs most of the Python files into that 
framework.  Some additional files are installed into the 
/Applications/Python x.y directory that the installer creates.  The 
Apple-supplied Pythons do not use either of these directories.

> Sometime in the recent past I remember installing, and then uninstalling 
> Python 3.x... so if I remove the 3.1 directory sub-tree, will that clean 
> out that bit so I can start over fresh?

If you want to clean out both the python.org 2.6 and 3.1 (the only two 
you've installed), the easiest thing to do is:

sudo rm -r /Library/Frameworks/Python.framework
sudo rm -r "/Applications/Python 2.6"
sudo rm -r "/Applications/Python 3.1"

You may also need to edit your shell startup file, likely 
~/.bash_profile or ~/.profile, to remove the modifications to put the 
framework bin directories at the head of $PATH.  And there should be 
some dangling symlinks left behind in /usr/local/bin which can be 
removed, things like /usr/local/bin/python2.6, /usr/local/bin/idle2.6, 
etc.

There is more detail here:  http://bugs.python.org/issue7107

-- 
 Ned Deily,
 nad at acm.org


From memilanuk at gmail.com  Sat Aug 28 19:25:38 2010
From: memilanuk at gmail.com (Monte Milanuk)
Date: Sat, 28 Aug 2010 10:25:38 -0700
Subject: [Pythonmac-SIG] 'Cleaning house' - getting back to just Apple's
	Python
In-Reply-To: <nad-D56D56.00314628082010@news.gmane.org>
References: <i59tqt$g55$1@dough.gmane.org>
	<nad-D56D56.00314628082010@news.gmane.org>
Message-ID: <i5bgqq$lql$1@dough.gmane.org>

On 8/28/10 12:31 AM, Ned Deily wrote:
>
> The Apple-supplied Pythons in 10.6 are 2.6.1 and 2.5.4.  They are
> invoked with /usr/bin/python2.6 (also /usr/bin/python) and
> /usr/bin/python2.5.  The Python Frameworks are in /System/Library.
> Don't try to remove any of this!

Roger that ;)  I see an older install of 2.3 floating around in there:

macbook:~ monte$ ls -al 
/System/Library/Frameworks/Python.framework/Versions/
total 8
drwxr-xr-x   6 root  wheel  204 May  6 15:31 .
drwxr-xr-x   7 root  wheel  238 Jul  4 20:35 ..
drwxr-xr-x   8 root  wheel  272 May  6 15:31 2.3
drwxr-xr-x  12 root  wheel  408 Jul  4 20:35 2.5
drwxr-xr-x  12 root  wheel  408 Jul  4 20:35 2.6
lrwxr-xr-x   1 root  wheel    3 May  6 15:31 Current -> 2.6
macbook:~ monte$

I presume the older version is from what was there before with 10.3 or 
10.4?

>
> If you want to clean out both the python.org 2.6 and 3.1 (the only two
> you've installed), the easiest thing to do is:

I purged everything as described, and cleaned a lot of cruft out of my 
.bash_profile and .profile files.  Looks like everything is more or less 
back to ground zero at this point.


Thank a bunch!

Monte


From memilanuk at gmail.com  Sat Aug 28 19:57:57 2010
From: memilanuk at gmail.com (Monte Milanuk)
Date: Sat, 28 Aug 2010 10:57:57 -0700
Subject: [Pythonmac-SIG] Which version to install?
Message-ID: <i5bind$sd3$1@dough.gmane.org>

Hello all,

Now that I have things more or less back to the original for 10.6 on my 
Macbook, I'd like to install a slightly more up-to-date version for 
learning to develop with.  Some of the things I'm interested in working 
with include wxpython/dabo, tkinter (with the new ttk themed widgets), 
pygame, etc.  On the one hand I'd rather just jump straight to 3.1.x at 
this point, but since a lot of the above don't seem to be ported to 3.x 
yet... I guess that limits my choices?

So... which route would you recommend, and why:  MacPython from 
python.org, Activestate Python, or MacPorts python.  Pros and cons would 
be appreciated.

Thanks,

Monte


From softw.devl at gmail.com  Sat Aug 28 20:11:49 2010
From: softw.devl at gmail.com (Melton Low)
Date: Sat, 28 Aug 2010 12:11:49 -0600
Subject: [Pythonmac-SIG] 'Cleaning house' - getting back to just Apple's
	Python
In-Reply-To: <i5bgqq$lql$1@dough.gmane.org>
References: <i59tqt$g55$1@dough.gmane.org>
	<nad-D56D56.00314628082010@news.gmane.org>
	<i5bgqq$lql$1@dough.gmane.org>
Message-ID: <AANLkTin-apHs1PLLSoJsK26PhCSyUPZS-wz6vzp7sVCp@mail.gmail.com>

On Sat, Aug 28, 2010 at 11:25 AM, Monte Milanuk <memilanuk at gmail.com> wrote:

> On 8/28/10 12:31 AM, Ned Deily wrote:
>
>>
>> The Apple-supplied Pythons in 10.6 are 2.6.1 and 2.5.4.  They are
>> invoked with /usr/bin/python2.6 (also /usr/bin/python) and
>> /usr/bin/python2.5.  The Python Frameworks are in /System/Library.
>> Don't try to remove any of this!
>>
>
> Roger that ;)  I see an older install of 2.3 floating around in there:
>
> macbook:~ monte$ ls -al
> /System/Library/Frameworks/Python.framework/Versions/
> total 8
> drwxr-xr-x   6 root  wheel  204 May  6 15:31 .
> drwxr-xr-x   7 root  wheel  238 Jul  4 20:35 ..
> drwxr-xr-x   8 root  wheel  272 May  6 15:31 2.3
> drwxr-xr-x  12 root  wheel  408 Jul  4 20:35 2.5
> drwxr-xr-x  12 root  wheel  408 Jul  4 20:35 2.6
> lrwxr-xr-x   1 root  wheel    3 May  6 15:31 Current -> 2.6
> macbook:~ monte$
>
> I presume the older version is from what was there before with 10.3 or
> 10.4?
>
>
>> If you want to clean out both the python.org 2.6 and 3.1 (the only two
>> you've installed), the easiest thing to do is:
>>
>
> I purged everything as described, and cleaned a lot of cruft out of my
> .bash_profile and .profile files.  Looks like everything is more or less
> back to ground zero at this point.
>
>
> Thank a bunch!
>
> Monte
>
> _______________________________________________
> 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
>

There have been other posts about the Apple supplied Python.  Anything in
the /System should not be touched.

Cheers, Mel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100828/88bb491d/attachment.html>

From nad at acm.org  Sat Aug 28 21:12:36 2010
From: nad at acm.org (Ned Deily)
Date: Sat, 28 Aug 2010 12:12:36 -0700
Subject: [Pythonmac-SIG] 'Cleaning house' - getting back to just Apple's
	Python
References: <i59tqt$g55$1@dough.gmane.org>
	<nad-D56D56.00314628082010@news.gmane.org>
	<i5bgqq$lql$1@dough.gmane.org>
	<AANLkTin-apHs1PLLSoJsK26PhCSyUPZS-wz6vzp7sVCp@mail.gmail.com>
Message-ID: <nad-378395.12123628082010@dough.gmane.org>

In article 
<AANLkTin-apHs1PLLSoJsK26PhCSyUPZS-wz6vzp7sVCp at mail.gmail.com>,
 Melton Low <softw.devl at gmail.com> wrote:
> On Sat, Aug 28, 2010 at 11:25 AM, Monte Milanuk <memilanuk at gmail.com> wrote:
> > Roger that ;)  I see an older install of 2.3 floating around in there:
> >
> > macbook:~ monte$ ls -al
> > /System/Library/Frameworks/Python.framework/Versions/
[...]
> > I presume the older version is from what was there before with 10.3 or
> > 10.4?

I believe the 2.3 library is still supplied by Apple with 10.6 for the 
benefit of applications that may have been dynamically linked to it in 
earlier releases of OS X.  (2.3 was the default in 10.4)

> There have been other posts about the Apple supplied Python.  Anything in
> the /System should not be touched.

Yep.

-- 
 Ned Deily,
 nad at acm.org


From hraban at fiee.net  Sat Aug 28 22:23:18 2010
From: hraban at fiee.net (Henning Hraban Ramm)
Date: Sat, 28 Aug 2010 22:23:18 +0200
Subject: [Pythonmac-SIG] Which version to install?
In-Reply-To: <i5bind$sd3$1@dough.gmane.org>
References: <i5bind$sd3$1@dough.gmane.org>
Message-ID: <BD582584-5DFC-4B37-AF70-31D0B33FA222@fiee.net>


Am 2010-08-28 um 19:57 schrieb Monte Milanuk:

> Hello all,
>
> Now that I have things more or less back to the original for 10.6 on  
> my Macbook, I'd like to install a slightly more up-to-date version  
> for learning to develop with.  Some of the things I'm interested in  
> working with include wxpython/dabo, tkinter (with the new ttk themed  
> widgets), pygame, etc.  On the one hand I'd rather just jump  
> straight to 3.1.x at this point, but since a lot of the above don't  
> seem to be ported to 3.x yet... I guess that limits my choices?

I'd recommend 2.6, since some libraries still don't work with 2.7  
(just saw on the dabo list: kinterbasdb); if you find that all major  
libraries that you need support 2.7, take that.
I guess it will need "some" more time, until 3.x is really usable,  
since some important libs aren't ported yet (and I don't know if they  
ever will).

> So... which route would you recommend, and why:  MacPython from  
> python.org, Activestate Python, or MacPorts python.  Pros and cons  
> would be appreciated.


I'd suggest the python.org disribution, since most binary packages are  
made for that.

I guess ActiveState's is also good (I had always good experience with  
their Python and Perl distributions f?r Windows), and perhaps they  
handled the Tk problems (see other threads on this list) better than  
others, I don't know - I'll never use Tk again.

If DarwinPorts have everything you need in the versions you need, you  
can also choose this way, esp. if you install a lot of ports anyway. I  
use their pythons only in their apps.

Since I use only python.org (sticking to what I know and works), I  
can't vote for one or the other.


Greetlings from Lake Constance!
Hraban
---
http://www.fiee.net
https://www.cacert.org (I'm an assurer)





From memilanuk at gmail.com  Sat Aug 28 23:20:59 2010
From: memilanuk at gmail.com (Monte Milanuk)
Date: Sat, 28 Aug 2010 14:20:59 -0700
Subject: [Pythonmac-SIG] 'Cleaning house' - getting back to just Apple's
	Python
In-Reply-To: <nad-378395.12123628082010@dough.gmane.org>
References: <i59tqt$g55$1@dough.gmane.org>	<nad-D56D56.00314628082010@news.gmane.org>	<i5bgqq$lql$1@dough.gmane.org>	<AANLkTin-apHs1PLLSoJsK26PhCSyUPZS-wz6vzp7sVCp@mail.gmail.com>
	<nad-378395.12123628082010@dough.gmane.org>
Message-ID: <i5buk0$4uv$1@dough.gmane.org>

On 8/28/10 12:12 PM, Ned Deily wrote:
> In article
> <AANLkTin-apHs1PLLSoJsK26PhCSyUPZS-wz6vzp7sVCp at mail.gmail.com>,
>   Melton Low<softw.devl at gmail.com>  wrote:
>> On Sat, Aug 28, 2010 at 11:25 AM, Monte Milanuk<memilanuk at gmail.com>  wrote:
>>> Roger that ;)  I see an older install of 2.3 floating around in there:
>>>
>>> macbook:~ monte$ ls -al
>>> /System/Library/Frameworks/Python.framework/Versions/
> [...]
>>> I presume the older version is from what was there before with 10.3 or
>>> 10.4?
>
> I believe the 2.3 library is still supplied by Apple with 10.6 for the
> benefit of applications that may have been dynamically linked to it in
> earlier releases of OS X.  (2.3 was the default in 10.4)
>
>> There have been other posts about the Apple supplied Python.  Anything in
>> the /System should not be touched.
>
> Yep.
>


Got it.  I'll leave well enough alone there.

Thanks,

Monte


From rowen at uw.edu  Mon Aug 30 20:54:04 2010
From: rowen at uw.edu (Russell E. Owen)
Date: Mon, 30 Aug 2010 11:54:04 -0700
Subject: [Pythonmac-SIG] Which version to install?
References: <i5bind$sd3$1@dough.gmane.org>
Message-ID: <rowen-50DF98.11540430082010@news.gmane.org>

In article <i5bind$sd3$1 at dough.gmane.org>,
 Monte Milanuk <memilanuk at gmail.com> wrote:

> Hello all,
> 
> Now that I have things more or less back to the original for 10.6 on my 
> Macbook, I'd like to install a slightly more up-to-date version for 
> learning to develop with.  Some of the things I'm interested in working 
> with include wxpython/dabo, tkinter (with the new ttk themed widgets), 
> pygame, etc.  On the one hand I'd rather just jump straight to 3.1.x at 
> this point, but since a lot of the above don't seem to be ported to 3.x 
> yet... I guess that limits my choices?
> 
> So... which route would you recommend, and why:  MacPython from 
> python.org, Activestate Python, or MacPorts python.  Pros and cons would 
> be appreciated.

Python 2.6 is safest for now. 2.7 is quite new and some Mac binaries 
aren't available for it. Ditto for 3.x.

Most Mac binary installers are produces for the Python from python.org.

However, the python.org binaries all use Tcl/Tk 8.4 (presumably because 
that is the version Apple ships with MacOS X), which does not support 
tile/ttk. If you really need tile some options are:
- Install tile in Tcl/Tk 8.4
- Install Tcl/Tk 8.5 and then build Python from source. (If you use 
packages such as matplotlib and PIL that talk to tcl/tk then also build 
those from source).

-- Russell


From ronaldoussoren at mac.com  Tue Aug 31 10:50:36 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 31 Aug 2010 10:50:36 +0200
Subject: [Pythonmac-SIG] Which version to install?
In-Reply-To: <rowen-50DF98.11540430082010@news.gmane.org>
References: <i5bind$sd3$1@dough.gmane.org>
	<rowen-50DF98.11540430082010@news.gmane.org>
Message-ID: <80DF3B3E-63DB-4AAA-B7C4-6A718964EC2F@mac.com>


On 30 Aug, 2010, at 20:54, Russell E. Owen wrote:

> 
> However, the python.org binaries all use Tcl/Tk 8.4 (presumably because 
> that is the version Apple ships with MacOS X), which does not support 
> tile/ttk.

Your assumption is correct: the python.org binaries are linked with Tk 8.4 because that is what Apple ships.

There will be an intel-only installer for 2.7.1 and 3.2 that does use Tk 8.5, I haven't had time to work on that  yet though (as usual the OSX port for Tk 8.5 contains backward incompatible changes for platform-specific behaviour like the application menu and those changes break IDLE; there is a patch for that on the python tracker which I need to properly test and integrate).

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100831/554b6bb2/attachment.bin>

From grubert at users.sourceforge.net  Tue Aug 31 11:06:39 2010
From: grubert at users.sourceforge.net (engelbert gruber)
Date: Tue, 31 Aug 2010 11:06:39 +0200
Subject: [Pythonmac-SIG] Which version to install?
In-Reply-To: <80DF3B3E-63DB-4AAA-B7C4-6A718964EC2F@mac.com>
References: <i5bind$sd3$1@dough.gmane.org>
	<rowen-50DF98.11540430082010@news.gmane.org>
	<80DF3B3E-63DB-4AAA-B7C4-6A718964EC2F@mac.com>
Message-ID: <AANLkTikwUGAkvPgoEmjdMAsrsgtFaezBjnqdpVabTXJs@mail.gmail.com>

on my mac it says wish8.5 if i start it from cmdline

and /usr/bin/python Tkinter.TkVersion is 8.5

or am i missing something ?

On Tue, Aug 31, 2010 at 10:50 AM, Ronald Oussoren
<ronaldoussoren at mac.com> wrote:
>
> On 30 Aug, 2010, at 20:54, Russell E. Owen wrote:
>
>>
>> However, the python.org binaries all use Tcl/Tk 8.4 (presumably because
>> that is the version Apple ships with MacOS X), which does not support
>> tile/ttk.
>
> Your assumption is correct: the python.org binaries are linked with Tk 8.4 because that is what Apple ships.
>
> There will be an intel-only installer for 2.7.1 and 3.2 that does use Tk 8.5, I haven't had time to work on that ?yet though (as usual the OSX port for Tk 8.5 contains backward incompatible changes for platform-specific behaviour like the application menu and those changes break IDLE; there is a patch for that on the python tracker which I need to properly test and integrate).
>
> Ronald
> _______________________________________________
> 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
>
>

From ronaldoussoren at mac.com  Tue Aug 31 11:12:50 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 31 Aug 2010 11:12:50 +0200
Subject: [Pythonmac-SIG] Which version to install?
In-Reply-To: <AANLkTikwUGAkvPgoEmjdMAsrsgtFaezBjnqdpVabTXJs@mail.gmail.com>
References: <i5bind$sd3$1@dough.gmane.org>
	<rowen-50DF98.11540430082010@news.gmane.org>
	<80DF3B3E-63DB-4AAA-B7C4-6A718964EC2F@mac.com>
	<AANLkTikwUGAkvPgoEmjdMAsrsgtFaezBjnqdpVabTXJs@mail.gmail.com>
Message-ID: <E7CE1EEE-F6B7-4CC4-8463-4692EAF54107@mac.com>


On 31 Aug, 2010, at 11:06, engelbert gruber wrote:

> on my mac it says wish8.5 if i start it from cmdline
> 
> and /usr/bin/python Tkinter.TkVersion is 8.5
> 
> or am i missing something ?

You're probably running OSX 10.6, which includes tk 8.5 and tk 8.4.   OSX 10.5 and earlier only ship with Tk 8.4.

That's why the 32-bit installers on python.org link with Tk 8.4, those installer work on OSX 10.3.9 or later and should have a working version of Tkinter out of the box because otherwise IDLE won't work.    It is technically possible to include a copy of Tk 8.5 with the python  installer, but that installer is huge as it is and including Tk 8.5 would increase the load on maintainers.

Ronald

> 
> On Tue, Aug 31, 2010 at 10:50 AM, Ronald Oussoren
> <ronaldoussoren at mac.com> wrote:
>> 
>> On 30 Aug, 2010, at 20:54, Russell E. Owen wrote:
>> 
>>> 
>>> However, the python.org binaries all use Tcl/Tk 8.4 (presumably because
>>> that is the version Apple ships with MacOS X), which does not support
>>> tile/ttk.
>> 
>> Your assumption is correct: the python.org binaries are linked with Tk 8.4 because that is what Apple ships.
>> 
>> There will be an intel-only installer for 2.7.1 and 3.2 that does use Tk 8.5, I haven't had time to work on that  yet though (as usual the OSX port for Tk 8.5 contains backward incompatible changes for platform-specific behaviour like the application menu and those changes break IDLE; there is a patch for that on the python tracker which I need to properly test and integrate).
>> 
>> Ronald
>> _______________________________________________
>> 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
>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100831/978341a7/attachment-0001.bin>

From nad at acm.org  Tue Aug 31 11:15:51 2010
From: nad at acm.org (Ned Deily)
Date: Tue, 31 Aug 2010 02:15:51 -0700
Subject: [Pythonmac-SIG] Which version to install?
References: <i5bind$sd3$1@dough.gmane.org>
	<rowen-50DF98.11540430082010@news.gmane.org>
	<80DF3B3E-63DB-4AAA-B7C4-6A718964EC2F@mac.com>
	<AANLkTikwUGAkvPgoEmjdMAsrsgtFaezBjnqdpVabTXJs@mail.gmail.com>
Message-ID: <nad-61F697.02155131082010@news.gmane.org>

In article 
<AANLkTikwUGAkvPgoEmjdMAsrsgtFaezBjnqdpVabTXJs at mail.gmail.com>,
 engelbert gruber <grubert at users.sourceforge.net> wrote:

> on my mac it says wish8.5 if i start it from cmdline
> 
> and /usr/bin/python Tkinter.TkVersion is 8.5
> 
> or am i missing something ?

You're using the Apple-supplied Python 2.6.1 in OS X 10.6.  That Python 
uses Apple's Tk 8.5.

-- 
 Ned Deily,
 nad at acm.org


From memilanuk at gmail.com  Tue Aug 31 14:06:26 2010
From: memilanuk at gmail.com (Monte Milanuk)
Date: Tue, 31 Aug 2010 05:06:26 -0700
Subject: [Pythonmac-SIG] Which version to install?
In-Reply-To: <nad-61F697.02155131082010@news.gmane.org>
References: <i5bind$sd3$1@dough.gmane.org>	<rowen-50DF98.11540430082010@news.gmane.org>	<80DF3B3E-63DB-4AAA-B7C4-6A718964EC2F@mac.com>	<AANLkTikwUGAkvPgoEmjdMAsrsgtFaezBjnqdpVabTXJs@mail.gmail.com>
	<nad-61F697.02155131082010@news.gmane.org>
Message-ID: <i5ir84$d37$1@dough.gmane.org>

On 8/31/10 2:15 AM, Ned Deily wrote:
>
> You're using the Apple-supplied Python 2.6.1 in OS X 10.6.  That Python
> uses Apple's Tk 8.5.
>


So... does the Apple-supplied Python 2.6.1 with Apple's Tk 8.5 have ttk 
squirreled away somewhere onboard?


From ronaldoussoren at mac.com  Tue Aug 31 14:23:14 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 31 Aug 2010 14:23:14 +0200
Subject: [Pythonmac-SIG] Which version to install?
In-Reply-To: <i5ir84$d37$1@dough.gmane.org>
References: <i5bind$sd3$1@dough.gmane.org>
	<rowen-50DF98.11540430082010@news.gmane.org>
	<80DF3B3E-63DB-4AAA-B7C4-6A718964EC2F@mac.com>
	<AANLkTikwUGAkvPgoEmjdMAsrsgtFaezBjnqdpVabTXJs@mail.gmail.com>
	<nad-61F697.02155131082010@news.gmane.org>
	<i5ir84$d37$1@dough.gmane.org>
Message-ID: <50BAD5AD-F6E1-41D1-BE41-06A3AE4AA43D@mac.com>


On 31 Aug, 2010, at 14:06, Monte Milanuk wrote:

> On 8/31/10 2:15 AM, Ned Deily wrote:
>> 
>> You're using the Apple-supplied Python 2.6.1 in OS X 10.6.  That Python
>> uses Apple's Tk 8.5.
>> 
> 
> 
> So... does the Apple-supplied Python 2.6.1 with Apple's Tk 8.5 have ttk squirreled away somewhere onboard?

No, ttk is new in python 2.7 (http://docs.python.org/whatsnew/2.7.html#ttk-themed-widgets-for-tk)

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100831/102ff983/attachment.bin>

From ronaldoussoren at mac.com  Tue Aug 31 15:52:25 2010
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Tue, 31 Aug 2010 15:52:25 +0200
Subject: [Pythonmac-SIG] python 2.6.6 installer
Message-ID: <7B82C205-AF49-45CB-864B-0FFE09FD6D08@mac.com>

Hi,

The MacOSX installer for python 2.6.6 can now be downloaded at <http://www.python.org/download/releases/2.6.6/>.

2.6.6 has been out for a week, but sadly enough I had completely missed the release-manager's message about this on the python-committers list.  Thanks to Ned for warning me about the release.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3567 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/pythonmac-sig/attachments/20100831/85109ab9/attachment.bin>

From memilanuk at gmail.com  Tue Aug 31 16:23:50 2010
From: memilanuk at gmail.com (Monte Milanuk)
Date: Tue, 31 Aug 2010 14:23:50 +0000 (UTC)
Subject: [Pythonmac-SIG] Which version to install?
References: <i5bind$sd3$1@dough.gmane.org>
	<rowen-50DF98.11540430082010@news.gmane.org>
	<80DF3B3E-63DB-4AAA-B7C4-6A718964EC2F@mac.com>
	<AANLkTikwUGAkvPgoEmjdMAsrsgtFaezBjnqdpVabTXJs@mail.gmail.com>
	<nad-61F697.02155131082010@news.gmane.org>
	<i5ir84$d37$1@dough.gmane.org>
	<50BAD5AD-F6E1-41D1-BE41-06A3AE4AA43D@mac.com>
Message-ID: <loom.20100831T162219-692@post.gmane.org>

Ronald Oussoren <ronaldoussoren <at> mac.com> writes:

> > So... does the Apple-supplied Python 2.6.1 with Apple's Tk 8.5 have ttk 
squirreled away somewhere onboard?
> 
> No, ttk is new in python 2.7 (http://docs.python.org/whatsnew/2.7.html#ttk-
themed-widgets-for-tk)
> 


Nuts ;)

Thanks,

Monte