🌐 Mailman 3 April 2006 - Pythonmac-SIG - python.org

hiding pyc files
by Michael Barber April 21, 2006

April 21, 2006

All the recent discussion of icons and filetypes has got me wondering: is there a way to get the Finder to hide all of the bytecode files? Presumably, this would require hiding files based on the filename extensions. I've been unable to find anything about that with Google; I get drowned in the flood of pages about how to hide the extensions, which is not what I'm looking for at all. Anyone have any idea about how it's done, or if it is even possible? Really, it's a pity that compiled bytecode files aren't prepended with a dot as well as getting the pyc extension. -- Michael

1 0

macho_standalone progress: how to call -archs from command line?
by Kevin Walzer April 20, 2006

April 20, 2006

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I had written a few days ago about getting this error when I try to run the latest macho_standalone on an app bundle in this fashion: macho_standalone ~/Desktop/Myapp.app: File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 20, in ? main() File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 17, in main standaloneApp(fn) File "/Library/Frameworks/Python.framework/Versions/Current/bin/macho_standalone", line 10, in standaloneApp files = MachOStandalone(path).run() TypeError: __init__() takes at least 3 arguments (2 given) Digging a bit deeper into the macholib code, I noted that MachOStandalone.py calls for an "archs" argument: class MachOStandalone(object): def __init__(self, base, archs, dest=None, graph=None, env=None, executable_path=None): self.base = os.path.join(os.path.abspath(base), '') if dest is None: dest = os.path.join(self.base, 'Contents', 'Frameworks') self.dest = dest self.mms = dict([[arch, FilteredMachOGraph(self, arch, graph=graph, env=env, executable_path=executable_path)] for arch in archs]) self.changemap = {} self.excludes = [] self.pending = deque() self.archs = archs So what I'm trying to figure out is how to correctly pass the "archs" argument in my command-line parameters. I've tried four variants: macho_standalone ~/Desktop/Myapp.app ppc macho_standalone ~/Desktop/Myapp.app "archs = 'ppc'" macho_standalone ~/Desktop/Myapp.app "archs = ['ppc']" macho_standalone ~/Desktop/Myapp.app -archs ppc All of these yield the same error message as above. I think I'm on the right track here, because when I hard-code the ppc architecture in the __init__ def above, macho_standalone works. def __init__(self, base, archs=['ppc'], dest=None, graph=None, env=None, executable_path=None): So what I need to do is find the correct magic to get the command-line args invoked properly. Does anyone have any suggestions? Thanks! - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFER7B4rTC5hIgjqTMRAoeZAJ9+Qt+6ggPfZhW++Hqn3JankmwTBgCeKz7Q Jlmo6RkuKDnizVoUDzjhMeo= =Vd/V -----END PGP SIGNATURE-----

1 2

Psycho & 2.4.3 universal
by Jacob Rus April 20, 2006

April 20, 2006

Hi, I couldn't compile [psyco][1] using the 2.4.3 universal version of Python on my 12" powerbook. I'm wondering if this is just a problem with universal Python, or if psycho doesn't compile in general under OS X. Thanks for any help, -Jacob [1]: http://psyco.sourceforge.net/ Here's what the terminal output looked like: $python setup.py build PROCESSOR = 'ivm' running build running build_py running build_ext building 'psyco._psyco' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -DALL_STATIC=1 -Ic/ivm -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c c/psyco.c -o build/temp.macosx-10.4-fat-2.4/c/psyco.o In file included from c/initialize.h:46, from c/psyco.c:14: c/dispatcher.c: In function ‘do_promotion_internal’: c/dispatcher.c:1794: error: invalid lvalue in assignment In file included from c/initialize.h:46, from c/psyco.c:14: c/dispatcher.c: In function ‘do_promotion_internal’: c/dispatcher.c:1794: error: invalid lvalue in assignment In file included from c/initialize.h:48, from c/psyco.c:14: c/psyfunc.c: In function ‘psyco_proxycode’: c/psyfunc.c:633: warning: pointer targets in passing argument 1 of ‘PyString_FromStringAndSize’ differ in signedness In file included from c/initialize.h:48, from c/psyco.c:14: c/psyfunc.c: In function ‘psyco_proxycode’: c/psyfunc.c:633: warning: pointer targets in passing argument 1 of ‘PyString_FromStringAndSize’ differ in signedness lipo: can't figure out the architecture type of: /var/tmp//ccUTzkfB.out error: command 'gcc' failed with exit status 1

4 4

Latest universal build is 404
by Kevin Walzer April 20, 2006

April 20, 2006

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After looking at my issues with macho_standalone, I realized I've been using the "official" universal download of MacPython: but Bob Ippolito's site recommends a more recent build available: http://pythonmac.org/packages/py24-fat/Universal-MacPython-2.4.3-2006-04-07… This comes up (today, at least) as a 404. Is there another place to get it? - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFER7onrTC5hIgjqTMRAj2HAKCUFFhH+8YDJIb3qAiLRUGcLYckAQCfTKEN DaZtL/B8m5AIj2ApVyKbBSk= =99+f -----END PGP SIGNATURE-----

2 1

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
by has April 20, 2006

April 20, 2006

Jacob Rus wrote: > > There's the flat logo, but the logo I was pointing to was a version > > that's shaded a bit to look slightly raised and rounded. > >Were you looking for something more like [this][1]? >[1]: http://hcs.harvard.edu/~jrus/python/Glassy-Icon.png The snake logo you've used there is an earlier, boxier attempt that's not as pleasing to the eye, and not the final version used on python.org. The version Bill means (I couldn't get his link to work) is this: http://www.fastmirrors.org/python/pub/beta.python.org/resources/design/newl… Each snake has a slight linear colour gradient running diagonally, and the outer edges are curved. I posted a list of what seems to be needed earlier (still not got time to do them myself though); see: http://mail.python.org/pipermail/pythonmac-sig/2006-April/016869.html To which one might also add a Python egg icon - maybe a 3D egg with the Python logo on it, or a closed cuboid package-style box, or a standard Lego-cube-like plugin icon. has -- http://freespace.virgin.net/hamish.sanderson/

11 24

Re: [Pythonmac-SIG] Fwd: MacPython icon mockup
by Brendan Simons April 20, 2006

April 20, 2006

On 20-Apr-06, at 5:51 AM, pythonmac-sig-request(a)python.org wrote: >> The regular .py files should probably be badged "Python" as well, > > I think that's overkill; you don't see other apps doing this sort > of thing. Have some faith in your own material. :) Don't forget > that file names will already have a '.py' suffix, so they're > already in the boat with 99% of other OS X files that identify > their type through their filename suffix. > > (BTW, .py files should also identify themselves as 'Python scripts' > when folk who don't know what '.py' means do a 'Get Info' in > Finder. But I think IDLE's plist still needs to be set up correctly > for that.) You do see other apps badging icons with the suffix. It's standard procedure for those files which can be opened by more than one editor/ reader. Take PDF for instance. The preview icon is there, but so is "PDF", as a reminder that you don't -really- need to open it with preview. Brendan

4 3

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 36, Issue 60
by Jon Schull April 20, 2006

April 20, 2006

>> >> >> On Apr 19, 2006, at 21:41, Christopher Barker wrote: >> >>> Well, a script is text, but a .pyc file is not Data. Maybe >>> "bytecode", >>> which is too long, or "bytes" or "code" or ".pyc" or ??? >> >> I think it should be an Apple with a bite out of it--get it? >> Apple, snake, apple, byte <grin>. >> I kill myself ;-) Okay obviously I need to shut up and go away >> now...Bye. > Actually, I think you nailed it... Apple, snake, tree of knowledge.... Two possible layouts are suggested by these images: http://www.fotosearch.com/BDX108/bxp26159/ http://it.rit.edu/~jis/pylogo/pylogo.png (if only I could really draw...) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull(a)digitalgoods.com fax: 978-246-0487 cell: 585-738-6696 > >

1 0

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 36, Issue 60
by Jon Schull April 20, 2006

April 20, 2006

> I think it should be an Apple with a bite out of it--get it? Apple, > snake, apple, byte <grin>. > I kill myself ;-) Okay obviously I need to shut up and go away > now...Bye. Actually, I think you nailed it... Apple, snake, tree of knowledge.... Two possible layouts are suggested by these images: http://www.fotosearch.com/BDX108/bxp26159/ http://it.rit.edu/~jis/pylogo/pylogo.png (if only I could really draw...) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 schull(a)digitalgoods.com fax: 978-246-0487 cell: 585-738-6696 On Apr 20, 2006, at 2:00 AM, pythonmac-sig-request(a)python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request(a)python.org > > You can reach the person managing the list at > pythonmac-sig-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > Today's Topics: > > 1. Re: Fwd: MacPython icon mockup (Brendan Simons) > 2. Re: Someone had PIL trouble on i386 10.4.6 Python 2.4 IIRC--I > succeeded this evening (Christopher Barker) > 3. Re: Fwd: MacPython icon mockup (Christopher Barker) > 4. Re: Fwd: MacPython icon mockup (Daniel Lord) > 5. Re: Fwd: MacPython icon mockup (Jacob Rus) > 6. Re: Unintsaller for Universal (kevin parks) > 7. Re: Fwd: MacPython icon mockup (Jacob Rus) > 8. Re: Fwd: MacPython icon mockup (Daniel Lord) > > From: Brendan Simons <brendansimons(a)yahoo.ca> > Date: April 20, 2006 12:37:41 AM EDT > To: pythonmac-sig(a)python.org, Jacob Rus <jrus(a)fas.harvard.edu> > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > > On 20-Apr-06, at 12:15 AM, pythonmac-sig-request(a)python.org wrote: > >> From: Jacob Rus <jrus(a)fas.harvard.edu> >> Date: April 19, 2006 10:06:34 PM EDT (CA) >> To: pythonmac-sig(a)python.org >> Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup >> >> >> Bill Janssen wrote: >>>> No, I disagree. If there is any text, it should be in dark gray 18 >>>> point Lucida Grande, as per the HIG. XCode uses colored file >>>> extensions in its document graphics because it deals with many >>>> different types of source files, and this keeps them >>>> distinguishable. >>> It's not just XCode. *Users* deal with many different kinds of >>> source files, and apparently the icons used in XCode are the ones >>> that Mac OS X uses generically. For example, look at the Finder >>> icon >>> for a Java source file, and you'll see that the XCode icon is used >>> there, as well. >> >> Yes, java source files get the xcode icons, because XCode is set >> up on your machine as the editor for java files (and registered as >> such with Launch Services). Similarly for c, etc. On my machine, >> some of these get XCode document icons, and some get TextMate >> document icons, because for me, TextMate is the editor for those >> file types. >> >> You miss my point, which is that python files don't need giant >> colored "py" splashed across them, if they have a distinguishable >> python icon. XCode does not follow the HIG, because it makes >> distinguishing c files from java files easier. Our new python >> icon will not have this problem, because it only needs to >> represent with one type of file. > > I agree completely. > >> >>> The greeked source code in the background of the document >>> indicates "source code", the file extension indicates the >>> language, and the color apparently indicates something as well, >>> though it's not clear (to me) just what. >> >> If you like, we could add some greeked source code. If we do, >> then the pyo/pyc files will need something other than random 1s >> and 0s to distinguish it, especially at small sizes. I'm open to >> suggestions. > > I tried colourizing the document, but it's nearly impossible to > find a colour that complements both the blue and yellow of the > logo. You could darken the paper slightly (not so much that you > couldn't read the word "DATA" though. > > Brendan > -- > Brendan Simons > > From: Christopher Barker <Chris.Barker(a)noaa.gov> > Date: April 20, 2006 12:39:25 AM EDT > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Someone had PIL trouble on i386 10.4.6 > Python 2.4 IIRC--I succeeded this evening > > > Daniel Lord wrote: > >> That sound reasonable, but not what I did--I installed them in / >> usr/ local/lib & include. > > I've done that, but the only way I could make sure that they got > statically linked was to make sure that there were not dynamic > versions of the same libs anywhere else on the search path, so I > found it easier to put them in a special place, and it's always > possible that I'd have the dynamic libs installed for some other > reason. > > -Chris > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > > > > From: Christopher Barker <Chris.Barker(a)noaa.gov> > Date: April 20, 2006 12:41:36 AM EDT > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > Jacob Rus wrote: >> Christopher Barker wrote: >> > They look great, but what the heck is "DATA"? >> It was has's [idea][1] for what a .pyo/.pyc icons should look >> like, similar to how script editor allows saving of plain >> text .applescript files with an icon labeled "TEXT". > > Well, a script is text, but a .pyc file is not Data. Maybe > "bytecode", which is too long, or "bytes" or "code" or ".pyc" or ??? > > In fact, I think the ones-and-zeros background without any words > might work just fine. > > -Chris > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > > > > From: Daniel Lord <daniellord(a)mac.com> > Date: April 20, 2006 1:33:22 AM EDT > To: Christopher Barker <Chris.Barker(a)noaa.gov> > Cc: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > > On Apr 19, 2006, at 21:41, Christopher Barker wrote: > >> Well, a script is text, but a .pyc file is not Data. Maybe >> "bytecode", >> which is too long, or "bytes" or "code" or ".pyc" or ??? > > I think it should be an Apple with a bite out of it--get it? Apple, > snake, apple, byte <grin>. > I kill myself ;-) Okay obviously I need to shut up and go away > now...Bye. > > > > > From: Jacob Rus <jrus(a)fas.harvard.edu> > Date: April 20, 2006 1:40:00 AM EDT > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > Christopher Barker wrote: >> Jacob Rus wrote: >>> Christopher Barker wrote: >>> > They look great, but what the heck is "DATA"? >>> It was has's [idea][1] for what a .pyo/.pyc icons should look >>> like, similar to how script editor allows saving of plain >>> text .applescript files with an icon labeled "TEXT". >> Well, a script is text, but a .pyc file is not Data. Maybe >> "bytecode", which is too long, or "bytes" or "code" or ".pyc" or ??? >> In fact, I think the ones-and-zeros background without any words >> might work just fine. > > Easy enough: http://hcs.harvard.edu/~jrus/python/pyc-icon- > variations.png > > Which do you prefer? > > -Jacob > > > > > > From: kevin parks <kevin(a)macosx.com> > Date: April 20, 2006 1:44:31 AM EDT > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Unintsaller for Universal > > > thank you bob you rock! > > \m/ (>.<) \m/ > > this totally works ... (for anyone else needing to dumb down to 2.4.1) > > cheers all... > > -kp-- > > > > On Apr 20, 2006, at 1:02 AM, Bob Ippolito wrote: > >> >> On Apr 19, 2006, at 7:55 PM, kevin parks wrote: >> >>> How do i uninstall 2.4.3? >>> so that i can dial back to 2.4.1? or am i screwed? >> >> I don't think there were any plans for an uninstaller. Just >> install 2.4.1 and everything will work fine, it'll overwrite >> everything that needs to be overwritten. >> >> -bob > > > > > > From: Jacob Rus <jrus(a)fas.harvard.edu> > Date: April 20, 2006 1:47:51 AM EDT > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > Brendan Simons wrote: >> I like it, but Aqua has tuned down a lot its glassiness in recent >> years. I would tone down the difference between highlights and >> shadows myself, but I'm not going to argue about it :) > > You're probably right, but make sure you look at the actual icon > files (in the zip files I linked to earlier) as well as the png > files. There are some icc profile mismatch issues here, which I > always seem to run into with png files (and it previews differently > in Camino and Safari, for instance). The actual version may be > duller than the preview you're seeing. Maybe I should post a > screenshot instead of saving from photoshop. > > -Jacob > > > > > > From: Daniel Lord <daniellord(a)mac.com> > Date: April 20, 2006 2:00:32 AM EDT > To: Jacob Rus <jrus(a)fas.harvard.edu> > Cc: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Fwd: MacPython icon mockup > > > > On Apr 19, 2006, at 22:47, Jacob Rus wrote: > >> Brendan Simons wrote: >>> I like it, but Aqua has tuned down a lot its glassiness in recent >>> years. I would tone down the difference between highlights and >>> shadows >>> myself, but I'm not going to argue about it :) >> >> You're probably right, but make sure you look at the actual icon >> files >> (in the zip files I linked to earlier) as well as the png files. >> There >> are some icc profile mismatch issues here, which I always seem to run >> into with png files (and it previews differently in Camino and >> Safari, >> for instance). The actual version may be duller than the preview >> you're >> seeing. Maybe I should post a screenshot instead of saving from >> photoshop. > > Jacob, > I think your 'glassiness' is understated and fine. I never meant > the extreme of the original colored iMac look. > I think it adds a nice 3-D look especially in the smaller sizes and > is under-stated enough to fit the Apple look of today with a little > of a yellow and blue color Apple doesn't use. Could it be turned > down a bit? Yeah I suppose. But there is a time to tweak and a time > to move on when the diminishing returns of tweaking are vanishingly > small and we can ignore subsequent terms in the series (flash-back > to advanced engineering math ;-). Guess what time I think it is IMHO? > > Daniel

1 0

Fixing the documentation...
by Bill Janssen April 20, 2006

April 20, 2006

Just looking at the docs, I'm trying to figure out what's good and what's bad. 1) We should no longer point people to Jack's site, we point them to the python.org Mac download page instead. 2) references to PythonIDE and PackageManager should go. 3) What about the following: 2. MacPython Modules 2.1 macpath -- MacOS path manipulation functions 2.2 macfs -- Various file system services 2.2.1 FSSpec Objects 2.2.2 Alias Objects 2.2.3 FInfo Objects 2.3 ic -- Access to Internet Config 2.3.1 IC Objects 2.4 MacOS -- Access to Mac OS interpreter features 2.5 macostools -- Convenience routines for file manipulation 2.6 findertools -- The finder's Apple Events interface 2.7 EasyDialogs -- Basic Macintosh dialogs 2.7.1 ProgressBar Objects 2.8 FrameWork -- Interactive application framework 2.8.1 Application Objects 2.8.2 Window Objects 2.8.3 ControlsWindow Object 2.8.4 ScrolledWindow Object 2.8.5 DialogWindow Objects 2.9 autoGIL -- Global Interpreter Lock handling in event loops 3. MacPython OSA Modules 3.1 gensuitemodule -- Generate OSA stub packages 3.2 aetools -- OSA client support 3.3 aepack -- Conversion between Python variables and AppleEvent data containers 3.4 aetypes -- AppleEvent objects 3.5 MiniAEFrame -- Open Scripting Architecture server support 3.5.1 AEServer Objects 4. MacOS Toolbox Modules 4.1 Carbon.AE -- Apple Events 4.2 Carbon.AH -- Apple Help 4.3 Carbon.App -- Appearance Manager 4.4 Carbon.CF -- Core Foundation 4.5 Carbon.CG -- Core Graphics 4.6 Carbon.CarbonEvt -- Carbon Event Manager 4.7 Carbon.Cm -- Component Manager 4.8 Carbon.Ctl -- Control Manager 4.9 Carbon.Dlg -- Dialog Manager 4.10 Carbon.Evt -- Event Manager 4.11 Carbon.Fm -- Font Manager 4.12 Carbon.Folder -- Folder Manager 4.13 Carbon.Help -- Help Manager 4.14 Carbon.List -- List Manager 4.15 Carbon.Menu -- Menu Manager 4.16 Carbon.Mlte -- MultiLingual Text Editor 4.17 Carbon.Qd -- QuickDraw 4.18 Carbon.Qdoffs -- QuickDraw Offscreen 4.19 Carbon.Qt -- QuickTime 4.20 Carbon.Res -- Resource Manager and Handles 4.21 Carbon.Scrap -- Scrap Manager 4.22 Carbon.Snd -- Sound Manager 4.23 Carbon.TE -- TextEdit 4.24 Carbon.Win -- Window Manager 4.25 ColorPicker -- Color selection dialog 5. Undocumented Modules 5.1 applesingle -- AppleSingle decoder 5.2 buildtools -- Helper module for BuildApplet and Friends 5.3 cfmfile -- Code Fragment Resource module 5.4 icopen -- Internet Config replacement for open() 5.5 macerrors -- Mac OS Errors 5.6 macresource -- Locate script resources 5.7 Nav -- NavServices calls 5.8 PixMapWrapper -- Wrapper for PixMap objects 5.9 videoreader -- Read QuickTime movies 5.10 W -- Widgets built on FrameWork 5.11 waste -- non-Apple TextEdit replacement My inclination is to delete them all :-). Except for ones where someone pipes up and tells me it still works. Let folks use the Wiki to find modules. 4) Should we document some of the newer stuff? py2app comes to mind. Bill

7 11

Re: [Pythonmac-SIG] Unintsaller for Universal
by kevin parks April 20, 2006

April 20, 2006

thank you bob you rock! \m/ (>.<) \m/ this totally works ... (for anyone else needing to dumb down to 2.4.1) cheers all... -kp-- On Apr 20, 2006, at 1:02 AM, Bob Ippolito wrote: > > On Apr 19, 2006, at 7:55 PM, kevin parks wrote: > >> How do i uninstall 2.4.3? >> so that i can dial back to 2.4.1? or am i screwed? > > I don't think there were any plans for an uninstaller. Just install > 2.4.1 and everything will work fine, it'll overwrite everything that > needs to be overwritten. > > -bob

2 1