Re: [Python-Dev] PEP 257 and __init__

2016-01-04 Thread Facundo Batista
On Mon, Jan 4, 2016 at 4:49 AM, Nick Coghlan wrote: > When some of the default settings for the pep8 utility became a > problem, I was able to talk to the developers and persuade them to > tune their defaults to be more in line with the actual PEP text, and > keep their

Re: [Python-Dev] PEP 257 and __init__

2016-01-04 Thread Guido van Rossum
On Sun, Jan 3, 2016 at 11:49 PM, Nick Coghlan wrote: > On 4 January 2016 at 17:01, Terry Reedy wrote: > > Ask the PSF/pypi people to either prohibit such names or require a > > disclaimer of some sort. They are inherently confusing: "I took a look > at > >

Re: [Python-Dev] PEP 257 and __init__

2016-01-03 Thread Guido van Rossum
On Tue, Dec 29, 2015 at 1:03 PM, Facundo Batista wrote: > On Tue, Dec 29, 2015 at 4:38 PM, Andrew Barnert > wrote: > > > Isn't the same thing true for every special method? There are lots of > classes where __add___ just says "a.__add__(b) = a + b"

Re: [Python-Dev] PEP 257 and __init__

2016-01-03 Thread Nick Coghlan
On 4 January 2016 at 17:01, Terry Reedy wrote: > Ask the PSF/pypi people to either prohibit such names or require a > disclaimer of some sort. They are inherently confusing: "I took a look at > pep008" does not mean that one even looked at the PEP. Even when the > context

Re: [Python-Dev] PEP 257 and __init__

2016-01-03 Thread Terry Reedy
On 1/3/2016 6:21 PM, Guido van Rossum wrote: On Tue, Dec 29, 2015 at 1:03 PM, Facundo Batista > wrote: On Tue, Dec 29, 2015 at 4:38 PM, Andrew Barnert > wrote: > Isn't the same

[Python-Dev] PEP 257 and __init__

2015-12-29 Thread Facundo Batista
Hola! (I was doubting in sending this mail to this list or to the normal one, but as it affects a "style recommendation" we propose for the whole community, I finally sent it here) I was reading PEP 257 and it says that all public methods from a class (including __init__) should have a

Re: [Python-Dev] PEP 257 and __init__

2015-12-29 Thread Andrew Barnert via Python-Dev
On Dec 29, 2015, at 13:03, Facundo Batista wrote: > >> On Tue, Dec 29, 2015 at 4:38 PM, Andrew Barnert wrote: >> I usually just don't bother. You can violate PEP 257 when it makes sense, >> just like PEP 8. They're just guidelines, not iron-clad

Re: [Python-Dev] PEP 257 and __init__

2015-12-29 Thread Ben Finney
Facundo Batista writes: > Note that I'm ok to include a docstring when the actual behaviour > would deviate from the expected one as per Reference Docs. My point is > to not make it mandatory. I disagree with the exception you're making for ‘__init__’. The parameters

Re: [Python-Dev] PEP 257 and __init__

2015-12-29 Thread Fred Drake
On Tue, Dec 29, 2015 at 1:27 PM, Facundo Batista wrote: > I was reading PEP 257 and it says that all public methods from a class > (including __init__) should have a docstring. > > Why __init__? > > It's behaviour is well defined (inits the instance), and the >

Re: [Python-Dev] PEP 257 and __init__

2015-12-29 Thread Facundo Batista
On Tue, Dec 29, 2015 at 4:38 PM, Andrew Barnert wrote: > Isn't the same thing true for every special method? There are lots of classes > where __add___ just says "a.__add__(b) = a + b" or (better following the PEP) > "Return self + value." But, in the rare case where the

Re: [Python-Dev] PEP 257 and __init__

2015-12-29 Thread Andrew Barnert via Python-Dev
On Dec 29, 2015, at 10:27, Facundo Batista wrote: > I was reading PEP 257 and it says that all public methods from a class > (including __init__) should have a docstring. > > Why __init__? > > It's behaviour is well defined (inits the instance), and the >

Re: [Python-Dev] PEP 257 and __init__

2015-12-29 Thread Terry Reedy
On 12/29/2015 2:40 PM, Fred Drake wrote: On Tue, Dec 29, 2015 at 1:27 PM, Facundo Batista wrote: I was reading PEP 257 and it says that all public methods from a class (including __init__) should have a docstring. Why __init__? It's behaviour is well defined (inits