Currently, I use `sys.exit([arg])` for exiting program and it works fine.
As described in the document:

If another type of object is passed, None is equivalent to passing zero, and any other object is printed to stderr and results in an exit code of 1.

However, if I want to exit the program with status 0 (or any numbers else except 1) and print necessary messages before exiting, I have to write:
```python
print("message")
sys.exit()
```
So why `sys.exit` takes a list of arguments (`[arg]`) as its parameter? Rather than something like `sys.exit(code:int=0, msg:str=None)`?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Mon, 13 Mar 2023 at 20:00, scruel tao <scruelt@hotmail.com> wrote:

Currently, I use `sys.exit([arg])` for exiting program and it works fine.
As described in the document:

If another type of object is passed, None is equivalent to passing zero, and any other object is printed to stderr and results in an exit code of 1.

However, if I want to exit the program with status 0 (or any numbers else except 1) and print necessary messages before exiting, I have to write:
```python
print("message")
sys.exit()
```
So why `sys.exit` takes a list of arguments (`[arg]`) as its parameter? Rather than something like `sys.exit(code:int=0, msg:str=None)`?

It doesn't actually take a list of arguments; the square brackets
indicate that arg is optional here. So you can either quickly print
out an error message and exit, or you can exit with any return code
you like, but for anything more complicated, just print and then exit.

It's worth noting, by the way, that sys.exit("error message") will
print that to STDERR, not to STDOUT, which mean that the equivalent
is:

print("error message", file=sys.stderr)
sys.exit(1)

Which is another reason to do things differently on success; if you're returning 0, you most likely want your output on STDOUT.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lars:

I totally understand your reasoning here, but in some way it follows the unix philosophy: Do only one thing, but do that good.

I understand, python is not strongly typed, so `sys.exit` will be able to accept any types parameters rather than just integer.
In order to handle such �other� types logic, I think this function already violated the unix philosophy, and there is no way to avoid it.

Cameron:

That kind of thing is an open ended can of worms. You're better off
writing your own `aort()` function

Thank you for your advice and example, I applied such wrappers for many years, this question comes more from �pythonic� discussion, because as I mentioned above, `sys.exit` can accept any types.

BTW, `sys.exit()` actually raises a `SystemExit` exception which is
handled by the `sys.excepthook` callback which handles any exception
which escapes from the programme uncaught.

Interesting, `raise SystemExit` seems to have the same behavior as `sys.exit`:

```shell
python -c "raise SystemExit(100)"
echo $?
<<< 100

python -c " import sys; sys.exit(100)"
echo $?
<<< 100

python -c "raise SystemExit('a�)"
<<< a
echo $?
<<< 1

python -c " import sys; sys.exit('a�)"
<<< a
echo $?
<<< 1

```

So, `sys.exit` is just a shortcut for `raise SystemExit`, or not? (Haven�t yet check the cpython source code)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-03-14 03:29, Thomas Passin wrote:

On 3/13/2023 10:34 PM, scruel tao wrote:

Lars:

I totally understand your reasoning here, but in some way it
follows the unix philosophy: Do only one thing, but do that good.

I understand, python is not strongly typed, so `sys.exit` will be
able to accept any types parameters rather than just integer. In
order to handle such “other” types logic, I think this function
already violated the unix philosophy, and there is no way to avoid
it.

Most Python folks will say the Python *is* fairly strongly typed, but
for a different definition of "type". That is, duck typing.

It's strongly typed but not statically typed, unless you count type
hints, which are optional.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/13/2023 10:34 PM, scruel tao wrote:

Lars:

I totally understand your reasoning here, but in some way it
follows the unix philosophy: Do only one thing, but do that good.

I understand, python is not strongly typed, so `sys.exit` will be
able to accept any types parameters rather than just integer. In
order to handle such “other” types logic, I think this function
already violated the unix philosophy, and there is no way to avoid
it.

Most Python folks will say the Python *is* fairly strongly typed, but
for a different definition of "type". That is, duck typing.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/13/2023 10:34 PM, scruel tao wrote:

Interesting, `raise SystemExit` seems to have the same behavior as `sys.exit`:

```shell
python -c "raise SystemExit(100)"
echo $?
<<< 100

python -c " import sys; sys.exit(100)"
echo $?
<<< 100

OTOH, you don't want to get too tricky:

(on Windows, obviously)
C:\Users\tom>py -c "import sys; sys.exit(type(100) == type('a'))"

C:\Users\tom>echo %ERRORLEVEL%
0

Presumably we wouldn't want to get an exit value of 0 for this case!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 3/13/2023 11:50 PM, MRAB wrote:

On 2023-03-14 03:29, Thomas Passin wrote:

On 3/13/2023 10:34 PM, scruel tao wrote:

Lars:

I totally understand your reasoning here, but in some way it
follows the unix philosophy: Do only one thing, but do that good.

I understand, python is not strongly typed, so `sys.exit` will be
able to accept any types parameters rather than just integer. In
order to handle such “other” types logic, I think this function
already violated the unix philosophy, and there is no way to avoid
it.

Most Python folks will say the Python *is* fairly strongly typed, but
for a different definition of "type". That is, duck typing.

It's strongly typed but not statically typed, unless you count type
hints, which are optional.

Yes, of course. That's pretty common knowledge.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 14 Mar 2023 at 15:28, Thomas Passin <list1@tompassin.net> wrote:

On 3/13/2023 10:34 PM, scruel tao wrote:

Interesting, `raise SystemExit` seems to have the same behavior as `sys.exit`:

```shell
python -c "raise SystemExit(100)"
echo $?
<<< 100

python -c " import sys; sys.exit(100)"
echo $?
<<< 100

OTOH, you don't want to get too tricky:

(on Windows, obviously)
C:\Users\tom>py -c "import sys; sys.exit(type(100) == type('a'))"

C:\Users\tom>echo %ERRORLEVEL%
0

Presumably we wouldn't want to get an exit value of 0 for this case!

Why? You passed the value False, which is 0. So it should behave as
documented, and exit 0.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)