Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #86541

Re: Python Worst Practices

Show all headers | View raw

On 26 February 2015 00:11:24 GMT+00:00, Ben Finney <ben+python@benfinney.id.au> wrote:
>> Yes, but my point is: You shouldn't need to rebind those names (or
>> have names "true" and "false" for 0 and 1).
>
>That's not what you asked, though. You asked “When would 0 mean true
>and
>1 mean false?” My answer: in all Unix shell contexts.
>
>> Instead, use "success" and "failure".
>
>You'd better borrow the time machine and tell the creators of Unix. The
>meme is already established for decades now.

0 = success and non-zero = failure is the meme established, rather than 0 = true, non-zero = false.

It's not just used by UNIX, and is not necessarily defined by the shell either (bash was mentioned elsewhere in the thread). There is probably a system that pre-dates UNIX that I uses/used this too, but I don't know.

C stdlib defines EXIT_SUCCESS = 0, yet C99 stdbool.h defines false = 0. That shells handle 0 as true and non-zero as false probably stems from this (or similar in older languages). The " true" command is defined to have an exit status of 0, and "false" an exit status of 1.

The value is better thought of an error level, where 0 is no error and non-zero is some error. The AmigaOS shell conventionally takes this further with higher values indicating more critical errors, there's even a "failat N" command that means exit the script if the error level is higher than N.

None of the above is a good reason to use error *or* success return values in Python--use exceptions!--but may be encountered when running other processes.

Simon

Back to comp.lang.python | Previous | Next | Find similar | Unroll thread

Thread

Re: Python Worst Practices Simon Ward <simon+python@bleah.co.uk> - 2015-02-26 20:10 +0000

csiph-web