Re: [Python-ideas] os.architecture
On Mon, Dec 30, 2013 at 10:39 AM, anatoly techtonik <techtonik@gmail.com> wrote:
download('http://www.libsdl.org/release/SDL2-2.0.1-win32-'+uname()[4])+'.zip')
Nothing personal, but that code is awful.
You're right, it's buggy because I didn't test it. Superfluous close parenthesis there. But my point is that the architecture is right there in the name, so you can save yourself the trouble and just use what comes from uname directly. ChrisA
Chris Angelico writes:
But my point is that the architecture is right there in the name, so you can save yourself the trouble and just use what comes from uname directly.
Except you probably can't. "x64" != "x86_64". (The latter is what my Intel Mac says; don't have a 64-bit machine with win32 on it handy.)
Ok. Architecture is a fail in terminology. The word "OS architecture" can mean many things, and it will be the same design flaw as os.name. How about os.bitness instead?
On Dec 30, 2013, at 0:56, anatoly techtonik <techtonik@gmail.com> wrote:
Ok. Architecture is a fail in terminology. The word "OS architecture" can mean many things, and it will be the same design flaw as os.name.
How about os.bitness instead?
You missed the part where you were told that os is for OS services, not platform (including hardware, interpreter, and OS) information. That, as you might guess, goes in platform. And it's already there, as you've been told at least three times, so there is no need to add it. Anyway, "bitness" by itself doesn't tell you whether it will return 32 or 64 when running a 32-bit Python on 64-bit Windows (much less when running a universal 64-bit-capable Python on 64-bit Mac in 32-bit mode). It's just as potentially ambiguous as the functions that already exist, and therefore no better than them. And of course they have the advantage of already existing, and working in older versions of Python, and so on. Instead of being bewildered by "what could platform possibly mean", just skim the docs, or use the builtin help.
On Mon, Dec 30, 2013 at 3:13 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
On Dec 30, 2013, at 0:56, anatoly techtonik <techtonik@gmail.com> wrote:
Ok. Architecture is a fail in terminology. The word "OS architecture" can mean many things, and it will be the same design flaw as os.name.
How about os.bitness instead?
You missed the part where you were told that os is for OS services, not platform (including hardware, interpreter, and OS) information.
I've heard your opinion. Now why do you think os is for OS services? Docs say os is about OS interfaces, to which bitness or architecture is interface information.
Anyway, "bitness" by itself doesn't tell you whether it will return 32 or 64 when running a 32-bit Python on 64-bit Windows
That's why it is "os.bitness", not "interpreter.bitness" or "cpu.bitness".
It's just as potentially ambiguous as the functions that already exist
Do you still think so after my example above?
anatoly techtonik writes:
I've heard your opinion. Now why do you think os is for OS services?
Because everything in there is a Python wrapper for an OS service, and because platfrom covers your use case. That may not be obvious to you. But AFAICT (once explained) it works for most Pythonistas and is a consistent point of view. Your suggestion is nowhere near TOOWTDI, so it's not going to happen.
participants (4)
-
anatoly techtonik -
Andrew Barnert -
Chris Angelico -
Stephen J. Turnbull