I don't see gestalt on PEP 3108, but it is a Mac module.
On 12 May, 2008, at 4:10, Benjamin Peterson wrote:
I don't see gestalt on PEP 3108, but it is a Mac module.
The only user in the stdlib is platform.py, and that could use a simple ctypes wrapper instead (like the one attached below)
Ronald
-- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
On 2008-05-12 04:10, Benjamin Peterson wrote:
I don't see gestalt on PEP 3108, but it is a Mac module.
I'm not sure what to make of that comment. What are you suggesting ?
gestalt is used on Macs to access system information. platform.py uses and probably a lot of Mac apps as well.
On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
On 2008-05-12 04:10, Benjamin Peterson wrote:
I don't see gestalt on PEP 3108, but it is a Mac module.
I'm not sure what to make of that comment. What are you suggesting ?
gestalt is used on Macs to access system information. platform.py uses and probably a lot of Mac apps as well.
PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules.
I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on dropping gestalt as it is a trivial module that's used by bits of the standard library.
Ronald
On 2008-05-13 11:38, Ronald Oussoren wrote:
On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
On 2008-05-12 04:10, Benjamin Peterson wrote:
I don't see gestalt on PEP 3108, but it is a Mac module.
I'm not sure what to make of that comment. What are you suggesting ?
gestalt is used on Macs to access system information. platform.py uses and probably a lot of Mac apps as well.
PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules.
I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on dropping gestalt as it is a trivial module that's used by bits of the standard library.
Thanks, I didn't realize that *all* of Lib/plat-mac was targeted for removal.
I think that those modules which make sense on Mac OS X should be moved to Lib/plat-darwin/, ie. gestalt.
On 13 May, 2008, at 11:58, M.-A. Lemburg wrote:
On 2008-05-13 11:38, Ronald Oussoren wrote:
On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
On 2008-05-12 04:10, Benjamin Peterson wrote:
I don't see gestalt on PEP 3108, but it is a Mac module.
I'm not sure what to make of that comment. What are you suggesting ?
gestalt is used on Macs to access system information. platform.py uses and probably a lot of Mac apps as well.
PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules. I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on dropping gestalt as it is a trivial module that's used by bits of the standard library.
Thanks, I didn't realize that *all* of Lib/plat-mac was targeted for removal.
I think that those modules which make sense on Mac OS X should be moved to Lib/plat-darwin/, ie. gestalt.
Why? Technically speaking "darwin" is yet another platform: the open- source unixy bits of OSX. I'd prefer to keep plat-mac, but one that's much smaller than the current tree.
Ronald
On 2008-05-13 12:09, Ronald Oussoren wrote:
On 13 May, 2008, at 11:58, M.-A. Lemburg wrote:
On 2008-05-13 11:38, Ronald Oussoren wrote:
On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
On 2008-05-12 04:10, Benjamin Peterson wrote:
I don't see gestalt on PEP 3108, but it is a Mac module.
I'm not sure what to make of that comment. What are you suggesting ?
gestalt is used on Macs to access system information. platform.py uses and probably a lot of Mac apps as well.
PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules. I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on dropping gestalt as it is a trivial module that's used by bits of the standard library.
Thanks, I didn't realize that *all* of Lib/plat-mac was targeted for removal.
I think that those modules which make sense on Mac OS X should be moved to Lib/plat-darwin/, ie. gestalt.
Why? Technically speaking "darwin" is yet another platform: the open-source unixy bits of OSX. I'd prefer to keep plat-mac, but one that's much smaller than the current tree.
Well, if you fire up Python on Mac OS X 10.4, you get:
Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on *darwin*
OTOH, sys.path still has both plat-mac and plat-darwin on it. Probably for historic reasons, I guess.
Either way, I'm -1 on removing the gestalt API, since it's needed by platform.py and there doesn't appear to be an alternative for getting at certain config information on Mac OS (but don't really care whether it's implemented as C module or using ctypes ;-).
On 13/05/2008, at 07:30, M.-A. Lemburg wrote:
Either way, I'm -1 on removing the gestalt API, since it's needed by platform.py and there doesn't appear to be an alternative for getting at certain config information on Mac OS (but don't really care whether it's implemented as C module or using ctypes ;-).
What happened to the idea of making it a ctypes module? I'm very much in favor to all non performance critical parts of python be in a more portable and easier to maintain code.
-- Leonardo Santagada
On 13 May, 2008, at 13:03, Leonardo Santagada wrote:
On 13/05/2008, at 07:30, M.-A. Lemburg wrote:
Either way, I'm -1 on removing the gestalt API, since it's needed by platform.py and there doesn't appear to be an alternative for getting at certain config information on Mac OS (but don't really care whether it's implemented as C module or using ctypes ;-).
What happened to the idea of making it a ctypes module?
AFAIK there is are no such plans.
I'm very much in favor to all non performance critical parts of python be in a more portable and easier to maintain code.
I'm -1 on rewriting it as a ctypes module. The existing C implementation works just fine, rewriting it in Python is just more work without clear advantages.
If you want to play with ctypes on OSX: look into replacing the Carbon.File usage in the modules plistlib and binhex by ctypes wrappers (both to remove the dependency on the now-deprecated Carbon bindings).
Ronald
-- Leonardo Santagada
stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
On Tue, May 13, 2008 at 4:25 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 13:03, Leonardo Santagada wrote:
On 13/05/2008, at 07:30, M.-A. Lemburg wrote:
Either way, I'm -1 on removing the gestalt API, since it's needed by platform.py and there doesn't appear to be an alternative for getting at certain config information on Mac OS (but don't really care whether it's implemented as C module or using ctypes ;-).
What happened to the idea of making it a ctypes module?
AFAIK there is are no such plans.
I'm very much in favor to all non performance critical parts of python be
in a more portable and easier to maintain code.
I'm -1 on rewriting it as a ctypes module. The existing C implementation works just fine, rewriting it in Python is just more work without clear advantages.
Then why did you attach a ctypes implementation two days ago?
-Brett
On 13 May, 2008, at 23:00, Brett Cannon wrote:
On Tue, May 13, 2008 at 4:25 AM, Ronald Oussoren <ronaldoussoren@mac.com
wrote:
On 13 May, 2008, at 13:03, Leonardo Santagada wrote:
On 13/05/2008, at 07:30, M.-A. Lemburg wrote:
Either way, I'm -1 on removing the gestalt API, since it's needed by platform.py and there doesn't appear to be an alternative for getting at certain config information on Mac OS (but don't really care whether it's implemented as C module or using ctypes ;-).
What happened to the idea of making it a ctypes module?
AFAIK there is are no such plans.
I'm very much in favor to all non performance critical parts of python be
in a more portable and easier to maintain code.
I'm -1 on rewriting it as a ctypes module. The existing C implementation works just fine, rewriting it in Python is just more work without clear advantages.
Then why did you attach a ctypes implementation two days ago?
To show that adding it would be easy. That version is completely untested an not compatible with the C version, fixing those issues takes time and I have no intention to do those changes.
Ronald
On Tue, May 13, 2008 at 3:09 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 11:58, M.-A. Lemburg wrote:
On 2008-05-13 11:38, Ronald Oussoren wrote:
On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
On 2008-05-12 04:10, Benjamin Peterson wrote:
I don't see gestalt on PEP 3108, but it is a Mac module.
I'm not sure what to make of that comment. What are you suggesting ?
gestalt is used on Macs to access system information. platform.py uses and probably a lot of Mac apps as well.
PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules. I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on
dropping gestalt as it is a trivial module that's used by bits of the standard library.
Thanks, I didn't realize that *all* of Lib/plat-mac was targeted for removal.
I think that those modules which make sense on Mac OS X should be moved to Lib/plat-darwin/, ie. gestalt.
Why? Technically speaking "darwin" is yet another platform: the open-source unixy bits of OSX. I'd prefer to keep plat-mac, but one that's much smaller than the current tree.
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
-Brett
On 2008-05-13 20:45, Brett Cannon wrote:
On Tue, May 13, 2008 at 3:09 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 11:58, M.-A. Lemburg wrote:
On 2008-05-13 11:38, Ronald Oussoren wrote:
On 13 May, 2008, at 11:23, M.-A. Lemburg wrote:
On 2008-05-12 04:10, Benjamin Peterson wrote:
I don't see gestalt on PEP 3108, but it is a Mac module.
I'm not sure what to make of that comment. What are you suggesting ?
gestalt is used on Macs to access system information. platform.py uses and probably a lot of Mac apps as well.
PEP3108 proposes to drop all of Lib/plat-mac and Mac/Modules. I'm definitely in favor of dropping the Carbon bindings, but I'm -0 on
dropping gestalt as it is a trivial module that's used by bits of the standard library.
Thanks, I didn't realize that *all* of Lib/plat-mac was targeted for removal.
I think that those modules which make sense on Mac OS X should be moved to Lib/plat-darwin/, ie. gestalt.
Why? Technically speaking "darwin" is yet another platform: the open-source unixy bits of OSX. I'd prefer to keep plat-mac, but one that's much smaller than the current tree.
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
Not really: the Lib/plat-<platform> names are taken from uname, so they would have to go into a Lib/plat-darwin for Mac OS X.
I'm not sure, but could imaging that Mac OS 9 and below returned 'mac' for uname, which would then have been the reason to have that directory.
Perhaps Jack could shed some light on this ?!
Thanks,
On 13 May, 2008, at 20:45, Brett Cannon wrote:
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
That won't be me, I barely have time to work on Python at the moment and am focussing all time I have on ensuring that Python2.6 will be the best possible release on OSX.
How did you change platform? That module uses gestalt to calculate the osx platform version and architecture.
Ronald
On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 20:45, Brett Cannon wrote:
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
That won't be me, I barely have time to work on Python at the moment and am focussing all time I have on ensuring that Python2.6 will be the best possible release on OSX.
How did you change platform? That module uses gestalt to calculate the osx platform version and architecture.
It looks like Benjamin didn't change it. The unit tests still passed, though, possibly because platform.mac_ver() has a fallback if the gestalt import failed.
I will create an issue to add back in gestalt. What about that little module for urllib to get proxy info? How is that coming along?
-Brett
On 14 May, 2008, at 22:07, Brett Cannon wrote:
On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren <ronaldoussoren@mac.com
wrote:
On 13 May, 2008, at 20:45, Brett Cannon wrote:
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
That won't be me, I barely have time to work on Python at the moment and am focussing all time I have on ensuring that Python2.6 will be the best possible release on OSX.
How did you change platform? That module uses gestalt to calculate the osx platform version and architecture.
It looks like Benjamin didn't change it. The unit tests still passed, though, possibly because platform.mac_ver() has a fallback if the gestalt import failed.
I guess I'll have to find some time to add some unittests for platform.mac_ver then ;-)
I will create an issue to add back in gestalt. What about that little module for urllib to get proxy info? How is that coming along?
That's already committed in the trunk, I guess it will be merged in py3k later on.
Ronald
On Wed, May 14, 2008 at 11:20 PM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 14 May, 2008, at 22:07, Brett Cannon wrote:
On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 20:45, Brett Cannon wrote:
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
That won't be me, I barely have time to work on Python at the moment and am focussing all time I have on ensuring that Python2.6 will be the best possible release on OSX.
How did you change platform? That module uses gestalt to calculate the osx platform version and architecture.
It looks like Benjamin didn't change it. The unit tests still passed, though, possibly because platform.mac_ver() has a fallback if the gestalt import failed.
I guess I'll have to find some time to add some unittests for platform.mac_ver then ;-)
I will create an issue to add back in gestalt. What about that little module for urllib to get proxy info? How is that coming along?
That's already committed in the trunk, I guess it will be merged in py3k later on.
I see the code using ctypes now. Assuming no one blocked the commit for 3.0, then yes, it will get backported. Although a quick check of svnmerge-integrated seems to suggest the commit was not backported during the last merge. Crap. I will have a look.
-Brett
On Thu, May 15, 2008 at 12:35 AM, Brett Cannon brett@python.org wrote:
On Wed, May 14, 2008 at 11:20 PM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 14 May, 2008, at 22:07, Brett Cannon wrote:
On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 20:45, Brett Cannon wrote:
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
That won't be me, I barely have time to work on Python at the moment and am focussing all time I have on ensuring that Python2.6 will be the best possible release on OSX.
How did you change platform? That module uses gestalt to calculate the osx platform version and architecture.
It looks like Benjamin didn't change it. The unit tests still passed, though, possibly because platform.mac_ver() has a fallback if the gestalt import failed.
I guess I'll have to find some time to add some unittests for platform.mac_ver then ;-)
I will create an issue to add back in gestalt. What about that little module for urllib to get proxy info? How is that coming along?
That's already committed in the trunk, I guess it will be merged in py3k later on.
I see the code using ctypes now. Assuming no one blocked the commit for 3.0, then yes, it will get backported. Although a quick check of svnmerge-integrated seems to suggest the commit was not backported during the last merge. Crap. I will have a look.
So it looks like no one has done a big merge in a little while. If the code doesn't make it over in the next merge then it will have to be merged explicitly.
-Brett
On 2008-05-14 22:07, Brett Cannon wrote:
On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 20:45, Brett Cannon wrote:
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
That won't be me, I barely have time to work on Python at the moment and am focussing all time I have on ensuring that Python2.6 will be the best possible release on OSX.
How did you change platform? That module uses gestalt to calculate the osx platform version and architecture.
It looks like Benjamin didn't change it. The unit tests still passed, though, possibly because platform.mac_ver() has a fallback if the gestalt import failed.
I will create an issue to add back in gestalt. What about that little module for urllib to get proxy info? How is that coming along?
Question: Are we going to leave gestalt in plat-mac/ or move it to plat-darwin/ ?
This basically maps to the question whether Py3k will still support Mac OS 9 or not.
On Thu, May 15, 2008 at 2:51 AM, M.-A. Lemburg mal@egenix.com wrote:
On 2008-05-14 22:07, Brett Cannon wrote:
On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 20:45, Brett Cannon wrote:
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
That won't be me, I barely have time to work on Python at the moment and am focussing all time I have on ensuring that Python2.6 will be the best possible release on OSX.
How did you change platform? That module uses gestalt to calculate the osx platform version and architecture.
It looks like Benjamin didn't change it. The unit tests still passed, though, possibly because platform.mac_ver() has a fallback if the gestalt import failed.
I will create an issue to add back in gestalt. What about that little module for urllib to get proxy info? How is that coming along?
Question: Are we going to leave gestalt in plat-mac/ or move it to plat-darwin/ ?
Well, if we stick with the C version, it should just go into Modules.
This basically maps to the question whether Py3k will still support Mac OS 9 or not.
Mac OS 9 support was removed at least a version ago.
-Brett
On 2008-05-15 20:33, Brett Cannon wrote:
On Thu, May 15, 2008 at 2:51 AM, M.-A. Lemburg mal@egenix.com wrote:
On 2008-05-14 22:07, Brett Cannon wrote:
On Wed, May 14, 2008 at 8:31 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On 13 May, 2008, at 20:45, Brett Cannon wrote:
At the moment, both directories and all files (including gestalt) have been removed, so whomever adds the file back can choose the directory. =)
That won't be me, I barely have time to work on Python at the moment and am focussing all time I have on ensuring that Python2.6 will be the best possible release on OSX.
How did you change platform? That module uses gestalt to calculate the osx platform version and architecture.
It looks like Benjamin didn't change it. The unit tests still passed, though, possibly because platform.mac_ver() has a fallback if the gestalt import failed.
I will create an issue to add back in gestalt. What about that little module for urllib to get proxy info? How is that coming along?
Question: Are we going to leave gestalt in plat-mac/ or move it to plat-darwin/ ?
Well, if we stick with the C version, it should just go into Modules.
It was in Mac/Modules/ and I had a look yesterday at getting it back in there, but the Mac build system looked to complicated to touch (esp. since gestalt is built as part of the Carbon lib stuff).
Someone else with more knowledge about the Mac build will have to give it a go.
This basically maps to the question whether Py3k will still support Mac OS 9 or not.
Mac OS 9 support was removed at least a version ago.
So lib-mac/ can basically stay gone or at least the modules still needed from there should be moved/revived to lib-darwin/.
On Friday, May 16, 2008, at 04:56PM, "M.-A. Lemburg" mal@egenix.com wrote:
Well, if we stick with the C version, it should just go into Modules.
It was in Mac/Modules/ and I had a look yesterday at getting it back in there, but the Mac build system looked to complicated to touch (esp. since gestalt is built as part of the Carbon lib stuff).
Someone else with more knowledge about the Mac build will have to give it a go.
Adding it to Modules shouldn't be to hard, the only special thing about the Mac libraries is that they require and addition link argument: "-framework Carbon".
This basically maps to the question whether Py3k will still support Mac OS 9 or not.
Mac OS 9 support was removed at least a version ago.
So lib-mac/ can basically stay gone or at least the modules still needed from there should be moved/revived to lib-darwin/.
I'm looking into this for python2.6 (although mostly to document the alternatives).
Ronald
On Fri, May 16, 2008 at 8:19 AM, Ronald Oussoren ronaldoussoren@mac.com wrote:
On Friday, May 16, 2008, at 04:56PM, "M.-A. Lemburg" mal@egenix.com wrote:
Well, if we stick with the C version, it should just go into Modules.
It was in Mac/Modules/ and I had a look yesterday at getting it back in there, but the Mac build system looked to complicated to touch (esp. since gestalt is built as part of the Carbon lib stuff).
Someone else with more knowledge about the Mac build will have to give it a go.
Adding it to Modules shouldn't be to hard, the only special thing about the Mac libraries is that they require and addition link argument: "-framework Carbon".
Well, do we want to continue with this Modules sub-directory or should it just end up in the Mac directory itself, ala the PC directory and its extension modules?
This basically maps to the question whether Py3k will still support Mac OS 9 or not.
Mac OS 9 support was removed at least a version ago.
So lib-mac/ can basically stay gone or at least the modules still needed from there should be moved/revived to lib-darwin/.
I'm looking into this for python2.6 (although mostly to document the alternatives).
Benjamin has a patch up on Issue2854 to add the module back, but I think it is for adding the code to Modules.
-Brett
-
Benjamin Peterson -
Brett Cannon -
Leonardo Santagada -
M.-A. Lemburg -
Ronald Oussoren