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


Groups > comp.lang.python > #91221

Re: Documentaion of dunder methods

Newsgroups comp.lang.python
Date 2015-05-25 19:36 -0700
References <5563d7bb$0$12982$c3e8da3$5496439d@news.astraweb.com>
Message-ID <abbde97b-2f04-456b-8975-3aa8bcdba67e@googlegroups.com> (permalink)
Subject Re: Documentaion of dunder methods
From Rustom Mody <rustompmody@gmail.com>

Show all headers | View raw


On Tuesday, May 26, 2015 at 7:47:41 AM UTC+5:30, Steven D'Aprano wrote:
> PEP 8 states that developers should never invent their own dunder methods:
> 
>     __double_leading_and_trailing_underscore__ : 
>         "magic" objects or attributes that live in user-controlled
>         namespaces. E.g. __init__ , __import__ or __file__ . Never 
>         invent such names; only use them as documented. 
> 
> https://www.python.org/dev/peps/pep-0008/#naming-conventions
> 
> 
> In other words, dunder methods are reserved for use by the core developers
> for the use of the Python interpreter.
> 
> Apart from PEP 8, is this documented anywhere in the official documentation?
> If so, I have been unable to find it.

Thanks for bringing this up.
dunder methods are a super-powerful and very pythonesque feature rendered 
somewhat useless by bad documentation.
Also I happen to disagree with (the literal rendering of your:

> In other words, dunder methods are reserved for use by the core developers
> for the use of the Python interpreter.

Of course defining YOUR OWN dunder method, disregarding the intended protocol
for that dunder method's usage, should not be done.
However if you interpret your statement as "Just dont go near them" it seems
like they are some kind of best-avoided leaky-abstraction of the (C)python 
implementation. And I guess you dont really want to assert that!!

What I'd like to see in the docs is something that 'zips' the operator table 
with the corresponding dunder method.  Something like:
| + | __add__ __radd__ |
| []| __getitem__ |
etc

Yeah I realize the most critical dunders dont 'have' an associated operator --
__init__.  But even there I'd put something like
|Class constructor¹| __init__

¹ Yeah I know about the 'initializer-vs-constructor' debates. Not really taking
a side on that one

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


Thread

Documentaion of dunder methods Steven D'Aprano <steve@pearwood.info> - 2015-05-26 12:17 +1000
  Re: Documentaion of dunder methods Rustom Mody <rustompmody@gmail.com> - 2015-05-25 19:36 -0700
  Re: Documentaion of dunder methods Steven D'Aprano <steve@pearwood.info> - 2015-05-26 13:17 +1000
    Re: Documentaion of dunder methods Rustom Mody <rustompmody@gmail.com> - 2015-05-25 20:30 -0700
      Re: Documentaion of dunder methods Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-26 08:24 +0100
  Re: Documentaion of dunder methods Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-25 22:34 -0600
    Re: Documentaion of dunder methods Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-26 17:12 +1000

csiph-web