
if os.architecture == 32: download('http://www.libsdl.org/release/SDL2-2.0.1-win32-x86.zip') else: download('http://www.libsdl.org/release/SDL2-2.0.1-win32-x64.zip') ?

On 29 December 2013 12:15, Chris Angelico <rosuav@gmail.com> wrote:
I would have thought so, and more accurately too. An AMD64 executable won't be much use on SPARC64, no matter that they are both 64-bit - the OP doesn't have this problem as his example is for Windows (at least as long as he's happy to ignore old Itanium systems). I hadn't realised that platform.uname() gave this information on Windows, but given that it does, it looks like a better solution for the OP's problem. Paul

On Sun, Dec 29, 2013 at 3:15 PM, Chris Angelico <rosuav@gmail.com> wrote:
If Python is about readability then looking at your example, I have two questions: 1. What is platform - hardware, CPU, OS, Python flavor? 2. What is uname()[4]? For os.architecture I have only one question - what is the returned value? And it is easy to remember once you get it. It is also easy to debug. -- anatoly t.

On Mon, Dec 30, 2013 at 6:38 AM, anatoly techtonik <techtonik@gmail.com> wrote:
You can also use platform.uname().machine if you prefer readability, but that doesn't work on Python 2. Number of bits is sufficient only if you can always assume you're on the same architecture. It's much better to simply quote the uname value. And hey, you can even cut your code down from four lines to one: download('http://www.libsdl.org/release/SDL2-2.0.1-win32-'+uname()[4])+'.zip') If you get back a 404, obviously this platform's not supported. Bingo! You've just protected yourself against trying to download and run Intel code on an ARM chip. ChrisA

anatoly techtonik writes:
On Sun, Dec 29, 2013 at 3:15 PM, Chris Angelico <rosuav@gmail.com> wrote:
Everything you might want in this area. (Note: 'os' is the wrong namespace for this. 'os' provides wrappers for OS services, not platform information.) In particular sum-65-1 08:16$ python Python 2.6.1 (r261:67515, Aug 2 2010, 20:10:18) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information.
Duh. Watch out for that time machine, Anatoly. For more information, RTFM or try python-list.

On Mon, Dec 30, 2013 at 2:30 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I want to know if I am running 32-bit or 64-bit Windows on my 64-bit CPU. So, how to resolve the ambiguity?
For OS information, 'os' is a logical namespace. I don't know about CPU info though. Would be nice to have 'hardware' or 'hwinfo' module in stdlib. I don't know where info about Python bitness should be.

On Dec 29, 2013, at 3:28, anatoly techtonik <techtonik@gmail.com> wrote:
Love it! A win32-x86 build is exactly what you want on 32-bit ARM9 linux, a win32-x64 build is perfect for ppc64 OS X. And if you're running a 32-bit python on 64-bit Windows you almost certainly want to download 64-bit libraries, right? I also love hard coding SDL 2.0.1 into your portable application, because there's no way they'll ever release a newer version without telling you in advance so you can forcibly update all your users, which makes their "latest" links useless.

On Mon, Dec 30, 2013 at 9:31 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
And if you're running a 32-bit python on 64-bit Windows you almost certainly want to download 64-bit libraries, right?
Actually, that one's a bit harder to work out. I'd say uname() would say that it's a 64-bit system (of whatever architecture), so all you have is the platform module and its methods of looking at sys.executable - and the docs comments kinda scare me off using that anywhere other than Linux (and even there, it looks inefficient). Is there a best-practice way of finding out what binary libraries you should be using for this process? Surely that should be a simple thing? ChrisA

On Dec 29, 2013, at 14:38, Chris Angelico <rosuav@gmail.com> wrote:
Sure. And this is all documented in the first place I would have thought to look--right near the top of the platform module, the first thing that comes up when I google "python platform" or "python architecture". There are actually 4 different things you could be asking for, not just 2 (even ignoring the fact that you can have different architectures that aren't just 32- and 64-bit versions of the same thing). What you really want here is probably not whether you're on a 64-bit OS, or whether Python was built 64-bit--if you ever care about any platform besides Windows, you may be running under a fat/universal binary that could be built for both 32- and 64-bit, and you want to know which one it's being _run_ as. So, as the docs say: To get at the "64-bitness" of the current interpreter, it is more reliable to query the sys.maxsize attribute. Maybe that could be given a nicer name, but adding an "os.architecture" that gives you a different of the four values than "platform.architecture" and probably isn't the one you want as Anatoly suggested doesn't seem like an improvement. Maybe we could have different functions in platform for hardware_architecture, os_architecture, executable_architecture, and interpreter_architecture? But I don't think they would get much use. Besides, historically I've been as interested in knowing whether I was on, say, real ARM7 or ARM9 emulating ARM7 as in real i386 or x86_64 emulating i386, where there's no simple 32 vs. 64 cross-platform answer that has any meaning, and I don't see any reason to believe that the future will be different, just because the present happens to be different on one platform.

On Sun Dec 29 2013 at 2:35:07 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
Using a fixed version isn't necessarily a terrible idea. While lots of libraries strive for backwards compatibility, that doesn't mean they don't sometimes break it (intentionally or accidentally). Always pulling down the latest version of a library can lead to trickier debugging.

On Mon, Dec 30, 2013 at 1:31 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
I am glad you've noticed this piece of code is for Windows. It is also nice that you understand the difference between OS bitness and Python bitness.
I also love hard coding SDL 2.0.1 into your portable application, because there's no way they'll ever release a newer version without telling you in advance so you can forcibly update all your users, which makes their "latest" links useless.
You'll like it even more if I tell you there is also a hash and size info hard coded. https://bitbucket.org/techtonik/locally/src/8367fad824c111367b99baf443c5d38b...

On 29 December 2013 12:15, Chris Angelico <rosuav@gmail.com> wrote:
I would have thought so, and more accurately too. An AMD64 executable won't be much use on SPARC64, no matter that they are both 64-bit - the OP doesn't have this problem as his example is for Windows (at least as long as he's happy to ignore old Itanium systems). I hadn't realised that platform.uname() gave this information on Windows, but given that it does, it looks like a better solution for the OP's problem. Paul

On Sun, Dec 29, 2013 at 3:15 PM, Chris Angelico <rosuav@gmail.com> wrote:
If Python is about readability then looking at your example, I have two questions: 1. What is platform - hardware, CPU, OS, Python flavor? 2. What is uname()[4]? For os.architecture I have only one question - what is the returned value? And it is easy to remember once you get it. It is also easy to debug. -- anatoly t.

On Mon, Dec 30, 2013 at 6:38 AM, anatoly techtonik <techtonik@gmail.com> wrote:
You can also use platform.uname().machine if you prefer readability, but that doesn't work on Python 2. Number of bits is sufficient only if you can always assume you're on the same architecture. It's much better to simply quote the uname value. And hey, you can even cut your code down from four lines to one: download('http://www.libsdl.org/release/SDL2-2.0.1-win32-'+uname()[4])+'.zip') If you get back a 404, obviously this platform's not supported. Bingo! You've just protected yourself against trying to download and run Intel code on an ARM chip. ChrisA

anatoly techtonik writes:
On Sun, Dec 29, 2013 at 3:15 PM, Chris Angelico <rosuav@gmail.com> wrote:
Everything you might want in this area. (Note: 'os' is the wrong namespace for this. 'os' provides wrappers for OS services, not platform information.) In particular sum-65-1 08:16$ python Python 2.6.1 (r261:67515, Aug 2 2010, 20:10:18) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information.
Duh. Watch out for that time machine, Anatoly. For more information, RTFM or try python-list.

On Mon, Dec 30, 2013 at 2:30 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I want to know if I am running 32-bit or 64-bit Windows on my 64-bit CPU. So, how to resolve the ambiguity?
For OS information, 'os' is a logical namespace. I don't know about CPU info though. Would be nice to have 'hardware' or 'hwinfo' module in stdlib. I don't know where info about Python bitness should be.

On Dec 29, 2013, at 3:28, anatoly techtonik <techtonik@gmail.com> wrote:
Love it! A win32-x86 build is exactly what you want on 32-bit ARM9 linux, a win32-x64 build is perfect for ppc64 OS X. And if you're running a 32-bit python on 64-bit Windows you almost certainly want to download 64-bit libraries, right? I also love hard coding SDL 2.0.1 into your portable application, because there's no way they'll ever release a newer version without telling you in advance so you can forcibly update all your users, which makes their "latest" links useless.

On Mon, Dec 30, 2013 at 9:31 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
And if you're running a 32-bit python on 64-bit Windows you almost certainly want to download 64-bit libraries, right?
Actually, that one's a bit harder to work out. I'd say uname() would say that it's a 64-bit system (of whatever architecture), so all you have is the platform module and its methods of looking at sys.executable - and the docs comments kinda scare me off using that anywhere other than Linux (and even there, it looks inefficient). Is there a best-practice way of finding out what binary libraries you should be using for this process? Surely that should be a simple thing? ChrisA

On Dec 29, 2013, at 14:38, Chris Angelico <rosuav@gmail.com> wrote:
Sure. And this is all documented in the first place I would have thought to look--right near the top of the platform module, the first thing that comes up when I google "python platform" or "python architecture". There are actually 4 different things you could be asking for, not just 2 (even ignoring the fact that you can have different architectures that aren't just 32- and 64-bit versions of the same thing). What you really want here is probably not whether you're on a 64-bit OS, or whether Python was built 64-bit--if you ever care about any platform besides Windows, you may be running under a fat/universal binary that could be built for both 32- and 64-bit, and you want to know which one it's being _run_ as. So, as the docs say: To get at the "64-bitness" of the current interpreter, it is more reliable to query the sys.maxsize attribute. Maybe that could be given a nicer name, but adding an "os.architecture" that gives you a different of the four values than "platform.architecture" and probably isn't the one you want as Anatoly suggested doesn't seem like an improvement. Maybe we could have different functions in platform for hardware_architecture, os_architecture, executable_architecture, and interpreter_architecture? But I don't think they would get much use. Besides, historically I've been as interested in knowing whether I was on, say, real ARM7 or ARM9 emulating ARM7 as in real i386 or x86_64 emulating i386, where there's no simple 32 vs. 64 cross-platform answer that has any meaning, and I don't see any reason to believe that the future will be different, just because the present happens to be different on one platform.

On Sun Dec 29 2013 at 2:35:07 PM, Andrew Barnert <abarnert@yahoo.com> wrote:
Using a fixed version isn't necessarily a terrible idea. While lots of libraries strive for backwards compatibility, that doesn't mean they don't sometimes break it (intentionally or accidentally). Always pulling down the latest version of a library can lead to trickier debugging.

On Mon, Dec 30, 2013 at 1:31 AM, Andrew Barnert <abarnert@yahoo.com> wrote:
I am glad you've noticed this piece of code is for Windows. It is also nice that you understand the difference between OS bitness and Python bitness.
I also love hard coding SDL 2.0.1 into your portable application, because there's no way they'll ever release a newer version without telling you in advance so you can forcibly update all your users, which makes their "latest" links useless.
You'll like it even more if I tell you there is also a hash and size info hard coded. https://bitbucket.org/techtonik/locally/src/8367fad824c111367b99baf443c5d38b...
participants (6)
-
Amber Yust
-
anatoly techtonik
-
Andrew Barnert
-
Chris Angelico
-
Paul Moore
-
Stephen J. Turnbull