Curses! I just noticed that sys.platform in 1.6a2 (and the latest CVS from this morning) returns "linux2" on my PC, not "linux-i386". As I recall this decision is made in the configure script. Does anyone know why it changed? This is not the end of the world, but the OS name alone is not really enough on a multi-architecture OS... ...back to calling os.uname() myself, I guess. ;-( Greg -- Greg Ward - programmer-at-big gward@python.net http://starship.python.net/~gward/ God made machine language; all the rest is the work of man.
Greg Ward writes:
I just noticed that sys.platform in 1.6a2 (and the latest CVS from this morning) returns "linux2" on my PC, not "linux-i386". As I recall this
I didn't know it ever returned linux-i386; perhaps you're thinking of Marc-Andre's platform module? -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
On 29 June 2000, Fred L. Drake, Jr. said:
I didn't know it ever returned linux-i386; perhaps you're thinking of Marc-Andre's platform module?
D'ohh! That appears to be an artifact of Red Hat's build -- I was using /usr/bin/python (theirs), not /usr/local/bin/python (mine). $ /usr/bin/python Python 1.5.2 (#1, Feb 1 2000, 16:32:16) [GCC egcs-2.91.66 19990314/Linux (egcs- on linux-i386 Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
sys.platform 'linux-i386'
Sorry for getting alarmist. Guess I never should have started using sys.platform in the first place (or just not worry about getting the CPU in there too). Greg -- Greg Ward - geek gward@python.net http://starship.python.net/~gward/ Support bacteria -- it's the only culture some people have!
"Fred L. Drake, Jr." wrote:
Greg Ward writes:
I just noticed that sys.platform in 1.6a2 (and the latest CVS from this morning) returns "linux2" on my PC, not "linux-i386". As I recall this
I didn't know it ever returned linux-i386; perhaps you're thinking of Marc-Andre's platform module?
Python has returned 'linux2' on my machine ever since I moved to a 2.x kernel -- why should it return 'linux-i386' (without any indication of version) ? As Fred mentioned, you should probably use platform.py to access the information you have in mind. It supports loads of different architectures and has pretty much all the information you need for distutils warpped in nice APIs. Why not simply include it in distutils ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Regarding platform.py: M.-A. Lemburg writes:
Why not simply include it in distutils ?
Why not include it in the standard library? Guido? I'll document it if Marc-Andre is willing to provide the module and the regression test. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
"Fred L. Drake, Jr." wrote:
Regarding platform.py:
M.-A. Lemburg writes:
Why not simply include it in distutils ?
Why not include it in the standard library? Guido? I'll document it if Marc-Andre is willing to provide the module and the regression test.
No objection from here. I've attached my most recent copy to this mail. I'm not sure how to write the regr. test though since output is dependent on the platform running the functions... perhaps I'll just add something like the audio thingie: "This string ought to identify the platform you are currently running... if not, then something is wrong ;-)". -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Ooops, forgot the attachement... -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Guido van Rossum wrote:
Regarding platform.py:
M.-A. Lemburg writes:
Why not simply include it in distutils ?
Why not include it in the standard library? Guido? I'll document it if Marc-Andre is willing to provide the module and the regression test.
No objection from here.
I've attached my most recent copy to this mail. I'm not sure how to write the regr. test though since output is dependent on the platform running the functions... perhaps I'll just add something like the audio thingie: "This string ought to identify the platform you are currently running... if not, then something is wrong ;-)".
You didn't include it!
I posted a reply to fix this ;-)
But I vote -1 on this one anyway -- it's too much code and almost by its very nature not something that belongs in a "standard" library. Plus, I don't want to be responsible for maintaining it. Sorry,
You don't have to maintain it... I will anyway since it's part of mxCGIPython. Anyway, perhaps Greg Ward can find some use for it in distutils. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On 30 June 2000, M.-A. Lemburg said:
But I vote -1 on this one anyway -- it's too much code and almost by its very nature not something that belongs in a "standard" library. Plus, I don't want to be responsible for maintaining it. Sorry,
You don't have to maintain it... I will anyway since it's part of mxCGIPython.
Anyway, perhaps Greg Ward can find some use for it in distutils.
I looked at platform.py once briefly, and my impression was similar to Guido's: too big! All I want(ed) is "osname-cpu" -- linux-i386, solaris-sparc, whatever. osversion is optional. But, consider that that the Distutils might want to know if it should generate RPMs or Debian packages... then the stuff about grokking which Linux distribution it's running on is relevant. Argh! Anyways, I'm already taking static about too much code in the Distutils, and I partly agree. (I agree there's a *lot* of code, I know there are bits that can be refactored and reduced, but I'm not sure it's too much.) So I'll stick with sys.platform for now -- it's good enough. Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367
Greg Ward writes:
But, consider that that the Distutils might want to know if it should generate RPMs or Debian packages... then the stuff about grokking which Linux distribution it's running on is relevant. Argh!
Why would you need to figure this out? Are you selecting a platform-specific packaging system automatically? In that case, I'd search for the presence of the tools rather than asking what sort of distribution you're running on -- several distros use RPM, a few use .deb packages, etc. When the user specifies one on the command line, just use the one they name and be done with it. -Fred -- Fred L. Drake, Jr. <fdrake at beopen.com> BeOpen PythonLabs Team Member
Regarding platform.py:
M.-A. Lemburg writes:
Why not simply include it in distutils ?
Why not include it in the standard library? Guido? I'll document it if Marc-Andre is willing to provide the module and the regression test.
No objection from here.
I've attached my most recent copy to this mail. I'm not sure how to write the regr. test though since output is dependent on the platform running the functions... perhaps I'll just add something like the audio thingie: "This string ought to identify the platform you are currently running... if not, then something is wrong ;-)".
You didn't include it! But I vote -1 on this one anyway -- it's too much code and almost by its very nature not something that belongs in a "standard" library. Plus, I don't want to be responsible for maintaining it. Sorry, --Guido van Rossum (home page: http://www.python.org/~guido/)
On 30 June 2000, Fred L. Drake, Jr. said:
Why would you need to figure this out? Are you selecting a platform-specific packaging system automatically? In that case, I'd search for the presence of the tools rather than asking what sort of distribution you're running on -- several distros use RPM, a few use .deb packages, etc. When the user specifies one on the command line, just use the one they name and be done with it.
Currently it's up to the user to decide which kind of built distribution they want, with stupid defaults: dumb tarball for Unix, dumb ZIP file for Windows. If you want an RPM or a Windows installer, you have to say so explicitly. This is not a big deal, but it might be nice to detect automatically if we can build (say) RPMs and do so. This is not a high-priority feature, though. I'll accept a patch if someone out there is interested enough to implement it. Greg
But I vote -1 on this one anyway -- it's too much code and almost by its very nature not something that belongs in a "standard" library. Plus, I don't want to be responsible for maintaining it. Sorry,
--Guido van Rossum (home page: http://www.python.org/~guido/)
Not that I hope to override the heavy -1, but I don't agree with the second point. It embodies a huge amount of knowledge that is needed to write portable code. As such, IMO, it _does_ belong in the standard library. How is it different in its nature from sys.platform, which is only a much weaker version of the same concept? --david
Not that I hope to override the heavy -1, but I don't agree with the second point. It embodies a huge amount of knowledge that is needed to write portable code. As such, IMO, it _does_ belong in the standard library. How is it different in its nature from sys.platform, which is only a much weaker version of the same concept?
A more subtle way of stating my opinion could be: if we were to do something in the standard distribution about the problems that this is addressing, I think we would do it in a much more direct fashion, e.g. by making the appropriate enquiry functions directly accessible.
--Guido van Rossum (home page: http://www.python.org/~guido/)
I much prefer that answer, as it leaves the door open to a patch. I don't care about the implementation, just the feature. Thanks. --david
Not that I hope to override the heavy -1, but I don't agree with the second point. It embodies a huge amount of knowledge that is needed to write portable code. As such, IMO, it _does_ belong in the standard library. How is it different in its nature from sys.platform, which is only a much weaker version of the same concept?
A more subtle way of stating my opinion could be: if we were to do something in the standard distribution about the problems that this is addressing, I think we would do it in a much more direct fashion, e.g. by making the appropriate enquiry functions directly accessible. --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
Not that I hope to override the heavy -1, but I don't agree with the second point. It embodies a huge amount of knowledge that is needed to write portable code. As such, IMO, it _does_ belong in the standard library. How is it different in its nature from sys.platform, which is only a much weaker version of the same concept?
A more subtle way of stating my opinion could be: if we were to do something in the standard distribution about the problems that this is addressing, I think we would do it in a much more direct fashion, e.g. by making the appropriate enquiry functions directly accessible.
platform.py does use the available functions on a couple of platforms... and it itself provides direct enquiry functions for Python programs to use. Perhaps I'm misunderstanding you here. Anyway, it's there for non-core programs to use and so far I think the core lib has managed to switch on sys.platform and do the right thing, so platform.py may not be all that necessary in the core. -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
participants (6)
-
David Ascher -
Fred L. Drake, Jr. -
Greg Ward -
Greg Ward -
Guido van Rossum -
M.-A. Lemburg