Re: [Pythonmac-SIG] [pythonmac-sig] python 2.7 tkinter using tk 8.6

[Stephen Gava]

On 22/05/10 1:21 AM, ronaldoussoren wrote:



On May 21, 2010, at 02:24 PM, Kevin Walzer  wrote:


On 5/21/10 1:16 AM, Stephen M. Gava wrote:
> Hi there,
> I've installed the python.org  package of python
2.7b2 for osx snow leopard.
>
> It's Tkinter appears to be built against Tk 84, but I want to use

[...]

two different builds of _tkinter) and automaticly selects the right
version to use.

What I'm thinking of is:

have _tkinterpy that does:

try:
from _tkinter85 import *
except ImportError:
from _tkinter84 import *

Then patch setup.py to build _tkinter84.so and _tkinter85.so from
_tkinter.c while linking to the right version of Tk. This should only be
done when a special configure argument is present, if it isn't setup.py
should default to building _tkinter.so like it currently does.

Ronald


hmm, sounds great. i don't have the c expertise to patch cpython tho.

i notice that the tcl/tk 'roadmap' for 8.6 mentions an immanent (last 
month) beta 2 release that will be a release candidate. of course these 
things (schedules) are _very_ rubbery with tcl-tk, but it would be nice 
if something like this tkinter tk choosing mechanism could be in place 
by the time there is an 'official' tk 8.6 release (lol, no rush, could 
be years yet...).


the native .png support is worth the price of admission to tk 8.6 alone 
i think, no faffing about with PIL builds for recent osx just to have 
.png images supported in your ui.


anyway, thanks for the replies,
stephen.








--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG


___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Problem packaging vtk application on Snow Leopard with py2app

[jens.thomas]

Hi,

I'm trying to package up an app under OSX 10.6 (MacBook with Intel Duo) with 
py2app. The application uses the external modules: vtk, numpy, Pmw.

When I try to package it up, I get the following error:

...lots of output...
Copying 
/Library/Python/2.6/site-packages/numpy-1.4.1-py2.6-macosx-10.6-universal.egg/numpy/version.pyc
 -> 
/Users/jmht/Documents/ccp1gui/dist/ccp1gui.app/Contents/Resources/lib/python2.6/numpy
creating 
/Users/jmht/Documents/ccp1gui/dist/ccp1gui.app/Contents/Resources/lib/python2.6/lib-dynload/vtk
Traceback (most recent call last):
  File 
"/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/build_app.py", 
line 589, in _run
self.run_normal()
  File 
"/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/build_app.py", 
line 660, in run_normal
self.create_binaries(py_files, pkgdirs, extensions, loader_files)
  File 
"/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/build_app.py", 
line 777, in create_binaries
platfiles = mm.run()
  File "build/bdist.macosx-10.6-universal/egg/macholib/MachOStandalone.py", 
line 101, in run
for fn in platfiles:
  File "build/bdist.macosx-10.6-universal/egg/macholib/util.py", line 227, in 
iter_platform_files
if is_platform_file(fn):
  File "build/bdist.macosx-10.6-universal/egg/macholib/util.py", line 206, in 
is_platform_file
header = mach_o.fat_header.from_fileobj(fileobj, _endian_='>')
  File "build/bdist.macosx-10.6-universal/egg/macholib/ptypes.py", line 44, in 
from_fileobj
return cls.from_str(f.read(cls._size_), **kw)
  File "build/bdist.macosx-10.6-universal/egg/macholib/ptypes.py", line 48, in 
from_str
return cls.from_tuple(struct.unpack(endian + cls._format_, s), **kw)
error: unpack requires a string argument of length 8


As py2app kindly fires up the debugger, I was able to look through the stack 
and see that:

endian + cls._format_ is '>LL' (i.e. big-endian with two unsigned longs)

the string s that was read in from the file is:

'\xca\xfe\xba\xbe\x00\x00\x00\x02\x00\x00\x00\x07\x00\x00\x00\x03'

which is of length 16, and cls._size_ is 16.

Everything points to 16 being the correct length, but the call to struct.unpack 
is expecting something of length 8.

I looked in the struct module and there is a 'calcsize' function which 
indicates what size is required for a specific format.

struct.calcsize('>LL') is 8 whereas struct.calcsize('LL') is 16

so it looks to me like the problem is with the format string.

Does anyone know if this is a bug in py2app, python or just something I'm doing 
wrong?

Any help/suggestions would be appreciated.

Thanks,

Jens

-- 
Scanned by iCritical.
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

[Pythonmac-SIG] Possible bug in setuptools/py2app

[jens.thomas]

Hi,

I've hit a problem trying to package up an application using py2app (this is on 
OSX 10.6). This is using the latest version of py2app as installed with 
easy_install.

My setup.py file lives in the top-level directory of the project directory 
(i.e. it's in the same directory as the python code for the project, which I 
think is a valid place for it to live).

When I try and package it up with py2app, the packaging fails because the paths 
to the data files that py2app looks for have the first character of their path 
lopped off and py2app crashes out as shown below:

running py2app
running build_py
creating build/bdist.macosx-10.6-universal/lib/ccp1gui/oc
error: can't copy 'oc/ccp1gui.zme.txt': doesn't exist or not a regular file


The correct path should be: "doc/ccp1gui.zme.txt"

I've managed to trace the problem to the file:

/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/setuptools/command/build_py.py

specifically the function _get_data_files, where there is the code:

# Length of path to strip from found files
plen = len(src_dir)+1

In my case,  src_dir is blank for the first package directory (I think because 
it's the same one as the one in which setup.py is running from), which is why 
it chops off the first character.

Is this a bug?

Many thanks,

Jens
-- 
Scanned by iCritical.
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Problem packaging vtk application on Snow Leopard with py2app

[Ronald Oussoren]

On 25 May, 2010, at 18:20, jens.tho...@stfc.ac.uk wrote:

> Hi,
> 
> I'm trying to package up an app under OSX 10.6 (MacBook with Intel Duo) with 
> py2app. The application uses the external modules: vtk, numpy, Pmw.
> 
> When I try to package it up, I get the following error:
> 
> ...lots of output...
> Copying 
> /Library/Python/2.6/site-packages/numpy-1.4.1-py2.6-macosx-10.6-universal.egg/numpy/version.pyc
>  -> 
> /Users/jmht/Documents/ccp1gui/dist/ccp1gui.app/Contents/Resources/lib/python2.6/numpy
> creating 
> /Users/jmht/Documents/ccp1gui/dist/ccp1gui.app/Contents/Resources/lib/python2.6/lib-dynload/vtk
> Traceback (most recent call last):
>  File 
> "/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/build_app.py",
>  line 589, in _run
>self.run_normal()
>  File 
> "/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/build_app.py",
>  line 660, in run_normal
>self.create_binaries(py_files, pkgdirs, extensions, loader_files)
>  File 
> "/Library/Python/2.6/site-packages/py2app-0.4.3-py2.6.egg/py2app/build_app.py",
>  line 777, in create_binaries
>platfiles = mm.run()
>  File "build/bdist.macosx-10.6-universal/egg/macholib/MachOStandalone.py", 
> line 101, in run
>for fn in platfiles:
>  File "build/bdist.macosx-10.6-universal/egg/macholib/util.py", line 227, in 
> iter_platform_files
>if is_platform_file(fn):
>  File "build/bdist.macosx-10.6-universal/egg/macholib/util.py", line 206, in 
> is_platform_file
>header = mach_o.fat_header.from_fileobj(fileobj, _endian_='>')
>  File "build/bdist.macosx-10.6-universal/egg/macholib/ptypes.py", line 44, in 
> from_fileobj
>return cls.from_str(f.read(cls._size_), **kw)
>  File "build/bdist.macosx-10.6-universal/egg/macholib/ptypes.py", line 48, in 
> from_str
>return cls.from_tuple(struct.unpack(endian + cls._format_, s), **kw)
> error: unpack requires a string argument of length 8
> 
> 
> As py2app kindly fires up the debugger, I was able to look through the stack 
> and see that:
> 
> endian + cls._format_ is '>LL' (i.e. big-endian with two unsigned longs)
> 
> the string s that was read in from the file is:
> 
> '\xca\xfe\xba\xbe\x00\x00\x00\x02\x00\x00\x00\x07\x00\x00\x00\x03'
> 
> which is of length 16, and cls._size_ is 16.
> 
> Everything points to 16 being the correct length, but the call to 
> struct.unpack is expecting something of length 8.

You seem to be running a 64-bit versions of python. There are some issues 
w.r.t. running py2app on 64-bit executables and you seem to run into one of 
them.

IIRC '>L' is always a 32-bit entity in the struct module, while the code 
expects it to be a 64-bit entity (for 64-bit binaries). Patching that should be 
fairly easy, but I don't have time to do that right now.

Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] Which version to use??

[Joe Hughes]

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

Thanks,
Joe

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

> 
> On 25 May, 2010, at 23:15, Rodney Somerstein wrote:
> 
>> At 10:08 PM +0200 5/25/10, Ronald Oussoren wrote:
>>> Python 3.1.2 works fine on OSX. There is an issue with building extensions 
>>> on OSX 10.6, but that will be fixed in 3.1.3.
>>> 
>>> PyObjC in the repository works with python 3 and I'm working towards a 
>>> release. I haven't looked into py2app yet. With some luck it will work 
>>> without major changes.
>> 
>> Good to hear. Thanks for the hard work on PyObjC. Do you have specific plans 
>> to look into py2app for Python 3?
> 
> I will look into py2app after the next release of PyObjC, which will happen 
> before python 2.7rc2 is released.
> 
>> 
 The Mac Python community seems pretty small. Given that Python seems to 
 position itself as a major programming and scripting language, it seems 
 rather strange that there is so little effort placed into providing first 
 class support for the second most popular computing platform. I know that 
 various individuals on this list put a tremendous amount of work into 
 porting and supporting various parts of Python on the Mac platform. But 
 what is the overall state of Python here? Especially in regards to Python 
 3, which seems to definitely be the future of the language.
>>> 
>>> Porting to py3k is an issue throughout the python community, mostly because 
>>> cleanly porting non-trivial projects takes time. What hasn't helped is that 
>>> a lot of project depend on setuptools and that didn't supported until 
>>> pretty recently (and that only through the 'distribute' fork).
>>> 
>>> As far as PyObjC is concerned port to py3k was a lot of work due to C-API 
>>> changes and because PyObjC tries to provide seemless integration between 
>>> Python and Cocoa, which means it is pretty sensitive to the large changes 
>>> between python 2.x and 3.x.
>>> 
>> 
>> It's great to see dedicated people such as yourself continuing this kind of 
>> work. Hopefully things will start to fall into place for Python 3.x. I see 
>> questions on comp.lang.python and elsewhere from people wanting to use 
>> Python 3.x as their main development language. I think many people, such as 
>> myself, are reluctant to jump into Python right now. My perception is that 
>> 2.x has a limited life span. It seems not to be the best choice to jump into 
>> that right now when the 3.x branch of the language itself is where most work 
>> seems to be going on. However, as you noted, many packages aren't trivial to 
>> port and that seems to be going very slowly.
> 
> 2.x has a limited life span indeed, but that's still a long time in Internet 
> time: 2.7 will be maintained at least 2 years and longer when there is reason 
> to do so.   The current consensus is that there will be no 2.8 though, which 
> means there will be no new features in 2.x after the release of 2.7 (later 
> this summer).
> 
> IMHO there is a chicken-and-egg problem: there aren't a lot of python 3 users 
> and hence there is little uptake in porting libraries to python 3. However, 
> the reason there aren't a lot of python 3 users is that a lot of libraries 
> aren't available yet.
> 
>> 
>> Are you planning on focusing on 3.x from this point forward with only 
>> maintenance on the 2.x version of PyObjC?
> 
> No. The C code for PyObjC contains lots of conditional code to be able to 
> compile with both branches, while the Python code translates cleanly with 
> 2to3. 
> 
> Having two development branches 
>> 
>> How far away is Python 3 from being the main branch of the language? Are we 
>> talking another year? 2? 5?
> 
> Most new work in CPython is done in python 3, and when 2.7 is released all 
> new features will only be 3.x.
> 
>> 
 I have looked at moving into Python several times over the years, but it 
 always seems to be a second class language when it comes to producing 
 programs to run on the Mac. At least outside of various command line 
 tools. Is Python moving toward parity with the Windows and Unix world on 
 the Macintosh?
>>> 
>>> What do you mean?  Python on OSX is support as well as it is on Linux and 
>>> Windows.
>> 
>> I'm not trying to denigrate the hard work that you and others put into 
>> keeping Python functioning well on the Mac. In part, due to the fact that 
>> packaging seems to be trickier for people to figure out with py2app than 
>> with py2exe I have gotten that impression. Maybe most people are usi

Re: [Pythonmac-SIG] Which version to use??

[ronaldoussoren]

On May 26, 2010, at 03:27 PM, Joe Hughes  wrote:I have some questions concerning what I'm reading below.  Ronald states that Python 3.1.2 works with PyObjC on OSX 10.6.  Is this with PyObjC 2.2 on the main site or some branch that is still experimental?  If this is experimental do I use RCS/CVS/Subversion to load it onto my Mac and compile it?  It has been many years since I last used an experimental branch and I forgot how to get it, but I also like using Python 3 on my Mac and have wanted to try PyObjC.This is with the version of pyobjc that is currently in the repository (the trunk). Building PyObjC is a bit of a hassle due to the large number of subprojects and I'd therefore advise against  installing from the repository unless you know what you're doing.I with some luck I'll upload a first beta of the next release before WWDC, I'm currently wrestling with my test environment: I've writting a script that builds and runs the unittests for all subprojects and that doesn't work entirely right for python 3.x yet. This is caused by bugs in some components I'm using, at least when building using python 3.2 (alpha version from the repository). I have to fix those issues before I can properly automate testing for the py3k portRonald

Thanks,
Joe

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

> 
> On 25 May, 2010, at 23:15, Rodney Somerstein wrote:
> 
>> At 10:08 PM +0200 5/25/10, Ronald Oussoren wrote:
>>> Python 3.1.2 works fine on OSX. There is an issue with building extensions on OSX 10.6, but that will be fixed in 3.1.3.
>>> 
>>> PyObjC in the repository works with python 3 and I'm working towards a release. I haven't looked into py2app yet. With some luck it will work without major changes.
>> 
>> Good to hear. Thanks for the hard work on PyObjC. Do you have specific plans to look into py2app for Python 3?
> 
> I will look into py2app after the next release of PyObjC, which will happen before python 2.7rc2 is released.
> 
>> 
 The Mac Python community seems pretty small. Given that Python seems to position itself as a major programming and scripting language, it seems rather strange that there is so little effort placed into providing first class support for the second most popular computing platform. I know that various individuals on this list put a tremendous amount of work into porting and supporting various parts of Python on the Mac platform. But what is the overall state of Python here? Especially in regards to Python 3, which seems to definitely be the future of the language.
>>> 
>>> Porting to py3k is an issue throughout the python community, mostly because cleanly porting non-trivial projects takes time. What hasn't helped is that a lot of project depend on setuptools and that didn't supported until pretty recently (and that only through the 'distribute' fork).
>>> 
>>> As far as PyObjC is concerned port to py3k was a lot of work due to C-API changes and because PyObjC tries to provide seemless integration between Python and Cocoa, which means it is pretty sensitive to the large changes between python 2.x and 3.x.
>>> 
>> 
>> It's great to see dedicated people such as yourself continuing this kind of work. Hopefully things will start to fall into place for Python 3.x. I see questions on comp.lang.python and elsewhere from people wanting to use Python 3.x as their main development language. I think many people, such as myself, are reluctant to jump into Python right now. My perception is that 2.x has a limited life span. It seems not to be the best choice to jump into that right now when the 3.x branch of the language itself is where most work seems to be going on. However, as you noted, many packages aren't trivial to port and that seems to be going very slowly.
> 
> 2.x has a limited life span indeed, but that's still a long time in Internet time: 2.7 will be maintained at least 2 years and longer when there is reason to do so.   The current consensus is that there will be no 2.8 though, which means there will be no new features in 2.x after the release of 2.7 (later this summer).
> 
> IMHO there is a chicken-and-egg problem: there aren't a lot of python 3 users and hence there is little uptake in porting libraries to python 3 However, the reason there aren't a lot of python 3 users is that a lot of libraries aren't available yet.
> 
>> 
>> Are you planning on focusing on 3.x from this point forward with only maintenance on the 2.x version of PyObjC?
> 
> No. The C code for PyObjC contains lots of conditional code to be able to compile with both branches, while the Python code translates cleanly with 2to3. 
> 
> Having two development branches 
>> 
>> How far away is Python 3 from being the main branch of the language? Are we talking another year? 2? 5?
> 
> Most new work in CPython is done in python 3, and when 2.7 is released all new features will only be 3.x.
> 
>> 
 I have looked at moving into Python several times over the years, but it always seems to be a second class

Re: [Pythonmac-SIG] Which version to use??

[Christopher Barker]

Ronald Oussoren wrote:


To be honest, I'm far from impressed by the quality of the wxWidgets
port to the Mac. I've run into numerous issues in the past where API
calls worked just fine on Windows but failed to work on OSX. That
isn't very helpfull when you want to do the groundwork of a Windows
app using wxWidgets on OSX and do as little as possible on an actual
windows machine.


Being a wx fan, I thought I'd comment. Ronald is absolutely correct -- 
there are platform differences -- there is no substitute for testing 
early and often on all the platforms you want to support. I've found 
that while it's fairly common for s given piece of code to work on one 
platform, but not another, I can usually find a way to write it that 
works everywhere -- and that's usually the documented "proper" way. i.e. 
you can get away with different errors on the different platforms.


However, while not perfect, what are the alternatives?

If you only want to support the Mac, then by all means use PyObjC -- 
that will give you a fully native application, but it is not an option 
if you want to support other platforms.


pyQT, pyGTK, and tkInter are the other options -- each has its fans, but 
none of them produce native looking and feeling apps on OS-X. wx wraps 
the native libs (Carbon for now, but the next version is Cocoa), so it's 
possible to have truly native Mac apps with wx, that are also native on 
Windows and *nix (of you call GTK native). Note that I say possible, 
because there are lot of details about how you design the apps t make 
them look and feel "right" on the Mac -- if you neglect those, it won't 
be quite right.


I suppose if you tweak a QT app enough, it might look native, but wx 
does a much better job out of the box.



The other option, of course, is to write multiple GUIs -- my experience 
is that it takes a LOT of code to write a GUI -- so that's a lot of work!


-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.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG

Re: [Pythonmac-SIG] [Image-SIG] PIL binaries -- please test

[Christopher Barker]

Yury V. Zaytsev wrote:

On Tue, 2010-05-25 at 12:57 -0700, Christopher Barker wrote:


If these work well, I think Fredrik will put them on the PIL site.


If you need a permanent mirror in the States, here you go:

http://packages.zaytsev.net/python/


Thanks, though ideally these would be available in a place everyone 
would know to look -- i.e. the PIL site.



What I would want to comment is that it would be nice for you to post
the history script / walk-through / whatever on how you created them, so
that other people would be able to reproduce this if you are busy /
unavailable etc. 


For instance, I have a whole bunch of Macs out there...


great -- are any of them running 10.4?

I have little time, but here is the short version:

The goal is to get a PIL binary that is statically linked to all of its 
dependencies, and those dependencies are all universal (32 bit PPC and 
Intel) and linked against the 10.4 sdk (or even the 10.3 one...)


I achieved all of this except for the 10.4 part...


 = Building the dependencies: =

This ended up being trivial with macports:

sudo port install jpeg +universal
sudo port install lcms +universal
sudo port install freetype +universal


 = Statically linking them when building PIL: =

This is trickier -- it turns out that the PIL setup.py already looks in 
the macports tree for libs. However, gcc prefers dynamic linking, so out 
of the box, it will dynamically link the dependencies -- fine on your 
machine, but not re-distributable.


I THINK there may be a way to tell gcc, through distutils, to statically 
link, but it's hard to find. However, if gcc only finds static libs, 
then it will link those.


In this case, I wasn't using macports for anything else on that machine, 
so what I did is re-name /opt/local/lib, and then create a new one that 
had only static libs in it. then I just ran setup,py build and presto: 
all was well.


The better way to do this would be to edit the setup.py to point to a 
place where the static libs are instead of mangling your macports install.


One other note about 10.4 -- the last time I tried to build teh deps n a 
10.4 machine, I had trouble -- I don't think there are a lot of macports 
devs on 10.4 any more, so it tends to be buggier.


To create the package, run bdist_mpkg, you can get that with easy-install

-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.bar...@noaa.gov
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG