Now that there are several people that want to support Apple's build
of python: how do we go forward from here?
I think we should start a small project for MacPython Addons, this
project will install:
* Hotfix for distutils to ensure that distutils builds univeral
binaries (32-bit only
Hi All,
I'm not sure whether this is the correct thread/place for this, but is
there any official best practice for Python under Leopard?
I.E., should we still be using the MacPython framework build (since I
assume that is more likely to track current python versions than the
Apple build). Is
On 3 Jan, 2008, at 15:18, Andrew Jaffe wrote:
Hi All,
I'm not sure whether this is the correct thread/place for this, but is
there any official best practice for Python under Leopard?
This is the right thread for that (albeith one with a lame subject).
I.E., should we still be using the
Ronald Oussoren wrote:
On 3 Jan, 2008, at 15:18, Andrew Jaffe wrote:
I'm not sure whether this is the correct thread/place for this, but is
there any official best practice for Python under Leopard?
I.E., should we still be using the MacPython framework build (since I
assume that is more
On 3 jan 2008, at 14:22, Ronald Oussoren wrote:
Now that there are several people that want to support Apple's build
of python: how do we go forward from here?
I think we should start a small project for MacPython Addons, this
project will install:
* Hotfix for distutils to ensure
Ronald Oussoren wrote:
I think we should start a small project for MacPython Addons,
This looks very promising. Thanks for getting it going.
this project will install:
* Hotfix for distutils to ensure that distutils builds univeral
binaries (32-bit only at first) * (possibly) hotfix to
On Jan 3, 2008, at 10:27 AM, Ronald Oussoren wrote:
I think that for true end users Idle is the only serious
omission. The first one is really for developers only, and the
second one doesn't really become important until such fat eggs
become widely available (which they are not right
* Hotfix for distutils to ensure that distutils builds univeral
binaries (32-bit only at first)
Is there a bug # for this? Possibly with a patch that we could start
with :-?
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
On Jan 3, 2008, at 5:27 PM, Ronald Oussoren wrote:
I want to do whatever keeps my live as easy as possible, either an
umbrella package with small hotfix packages or one package that
installs all hotfixes. I also want to keep the addon package as
small as possible and don't want to end
On 3 Jan, 2008, at 19:28, Tobias Rodäbel wrote:
On Jan 3, 2008, at 5:27 PM, Ronald Oussoren wrote:
I want to do whatever keeps my live as easy as possible, either an
umbrella package with small hotfix packages or one package that
installs all hotfixes. I also want to keep the addon
Christopher Barker wrote:
* What about people installing upgrades to packages? IIUC, the Apple
python puts stuff in a dir that is before site-packages, so if you
install a newer version of a package that Apple already had, it won't be
used without sys.path manipulations. I think numpy was
On 31 Dec 2007, at 14:09, Ronald Oussoren wrote:
[cc.d to Bob for his info]
That's a buglet in Python, fixed in what will be 2.5.2. Apple's
python doesn't do universal binaries and setuptools doesn't know
that an 'fat' egg will do on a 'ppc' or 'i386' platform.
After further poking, it
I'm looking for a Python API that will return the path to an icon file
which I can then read via PIL and display in my application.
The available API's that I can find--NSWorkspace and
IconServices--provide various hooks to obtaining and displaying an icon,
but neither appears to support
On 3 Jan, 2008, at 23:08, Kevin Walzer wrote:
I'm looking for a Python API that will return the path to an icon file
which I can then read via PIL and display in my application.
The available API's that I can find--NSWorkspace and
IconServices--provide various hooks to obtaining and
14 matches
Mail list logo
