Change the identation base value?

[scruel tao]

Currently, we have following PEP:
PEP 8: E114 indentation is not a multiple of 4 (comment)

However, I wonder how many people are using 2 spaces as their code indentation 
in projects? Should it be nesserary for us to change this PEP from “multiple of 
4” to “multiple of 2”?

-- 
https://mail.python.org/mailman/listinfo/python-list

Add angle brackets for required args in argparse

[scruel tao]

If we have the following code:
```
parser = argparse.ArgumentParser(description="test")
parser.add_argument('path')
```

Run it without args, will get error message:
```
usage: test.py [-h] path
test.py: error: the following arguments are required: path
```

However, I hope the message can be as the following:
```
usage: test.py [-h] 
test.py: error: the following arguments are required: path
```

Or might can consider to provide a way to let user have there own style, like:
```
usage: test.py [-h] path
```

Thanks.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Add angle brackets for required args in argparse

[scruel tao]

Thank you for your workarounds, Mark Bourne.
`metavar` argument should be sufficient  for infrequent use scenarios, and I 
will consider to use the custom help formatter if necessary.

>>> That's a bit closer to what you asked for, since the required argument
>>> shown in the error message doesn't include the angle brackets.  It also
>>> avoids needing to specify a `metavar` for every positional argument.
>>> However, it is overriding a non-public method of the `HelpFormatter`
>>> class, so might not work across all Python versions if the name or
>>> signature of that method changes (even if it does work with all current
>>> versions, it might break in future).

Your are right to be concerned, that’s why I still think, might the `argparse` 
can provide a more stable way which can set such format strategy globally, your 
workarounds are fine to work now, just I have to write the same code to parse 
either `metaver` or `formatter` every times I use argparse.
Might can have different argparse subclasses, or make some HelpFormatter 
builtin, so that users won’t need to write them by themselves.
-- 
https://mail.python.org/mailman/listinfo/python-list

How to exit program with custom code and custom message?

[scruel tao]

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)`?
-- 
https://mail.python.org/mailman/listinfo/python-list

转发: How to exit program with custom code and custom message?

[scruel tao]

Chris:
> It doesn't actually take a list of arguments; the square brackets
indicate that arg is optional here.

Oh, I see, it seems that I mistunderstood the document.

> 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:

Yes, I know, but don’t you think if `sys.exit` can take more parameters and 
have a default output channel selection strategy will be better?
Thanks.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to exit program with custom code and custom message?

[scruel tao]

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)
-- 
https://mail.python.org/mailman/listinfo/python-list

We can call methods of parenet class without initliaze it?

[scruel tao]

The following code won’t be allowed in Java, but in python, it works fine:
```python
class A:
A = 3

def __init__(self):
print(self.A)

def p(self):
print(self.A)
self.A += 1


class B(A):
def __init__(self):
print(2)
self.p()
super().__init__()


B()
```

How can I understand this? Will it be a problem?
-- 
https://mail.python.org/mailman/listinfo/python-list

Why doc call `__init__` as a method rather than function?

[scruel tao via Python-list]

```python
>>> class A:
...   def __init__(self):
... pass
...
>>> A.__init__

>>> a = A()
>>> a.__init__
>
```

On many books and even the official documents, it seems that many authors 
prefer to call `__init__` as a "method" rather than a "function".
The book PYTHON CRASH COURSE  mentioned that "A function that’s part of a class 
is a method.", however, ` A.__init__` tells that `__init__` is a function...

I wonder how can I call `__init__` as? Consider the output above.
Maybe both are OK? If you prefer or think that we must use one of the two, 
please explain the why, I really want to know, thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Why doc call `__init__` as a method rather than function?

[scruel tao via Python-list]

Thanks for all repliers:
@Tony & @Cameron, I do know related stuffs about the dunder methods, and your 
explanation just make it to be more clear, thank you!
@Roel, you just caught everyone here, we do miss it even though we know it and 
use it regularly!

@Clara
> its both, depending on how you're getting it.
Might can be more clear: its both, depending on how you're using/getting it.

And I think I can mark this question as resolved, and with the following 
conclusions:
As @Clara mentioned, we need to know that "all methods are functions", so we do 
can call `__init__` as a method or a function, or we can be avoid to have such 
discussion like Dan, and call it "the initializer" (However, you will need to 
think about “what is this is” for other functions :). ).
As @Alan mentioned, and according to the Wikipedia, in computer programming 
field, "method" is:
> A method in object-oriented programming (OOP) is a procedure associated with 
> an object, and generally also a message. An object consists of state data and 
> behavior; these compose an interface, which specifies how the object may be 
> used. A method is a behavior of an object parametrized by a user.

For `__init__` and other functions  in classes, we usually use them by writing 
code `obj.action()`, so we usually will call them as methods, so here, we call 
`action` or `__init__` as a method.
However, if you use them by writing code `Clz.action(obj)`, then you'd better 
(or must?) to call them as functions, and it is not a "daily use case" in daily 
development, and in some languages, this behavior won't even be possible.
**So, its kinda a "Majority rule" to call `__init__` (functions in classes) as 
a method.**

===
BTW, in Wikipedia, the "static methods" section is a very interesting:
> Static methods are meant to be relevant to all the instances of a class 
> rather than to any specific instance.
This explanation might can "group" some functions back to "methods" :) However, 
let's still remember:
All methods are functions, but not every function is a method.

Thanks again for helping, you guys are really nice!

-- 
https://mail.python.org/mailman/listinfo/python-list