[ddavis]

> Keep in mind that you're not meant to invent your own dunder methods. Sometimes you'll see third-party libraries that do invent their own dunder method, but this isn't encouraged and it can be quite confusing for users who run across such methods and assume they're "real" dunder methods.

I don't think this is good advice. Example: the dunder methods implemented and used by the Scientific Python/PyData community (__array__, __array_ufunc__, __array_func__, etc.) are so, so, so important to that ecosystem.

[ayhanfuat]

I think it is good advice. These are reserved for future use. If you define `__data__` and then Python decides to use it, it will cause problems. See "Reserved classes of identifiers" in the Python docs: https://docs.python.org/3/reference/lexical_analysis.html#re...

> System-defined names, informally known as “dunder” names. These names are defined by the interpreter and its implementation (including the standard library). Current system names are discussed in the Special method names section and elsewhere. More will likely be defined in future versions of Python. Any use of __*__ names, in any context, that does not follow explicitly documented use, is subject to breakage without warning.

[ddavis]

Yea there's some nuance here. But one of the beautiful things about Python is the existence of PEPs. One would have to write a PEP to get a new dunder method added to CPython. During the review/discussion of the PEP it would come up that one of the most popular ecosystems in all of Python would be impacted by adding a builtin __array__ dunder method, for example. It just wouldn't happen. It makes sense to me that the biggest packages associated with a language can have some impact on the way the language moves forward, even if they are not part of the core implementation. For example, the impact of PEP 563 on Pydantic (another wildly popular package outside of core) caused it to be rolled back.

[jameshart]

I propose that we refer to the practice of modules declaring their own dunder methods as “Dunder Miffling”.

Such declarations MUST be preceded by the comment:

   # I DECLARE

[darkflame91]

Alternatively, a Boolean variable 'bankruptcy' can be declared in the class to indicate the use of dunder-miffling.

[kodablah]

They didn't have to be dunder methods though, they could have used any other naming scheme (e.g. just `__` at the beginning, EDIT: or something else) and remained just as important in the ecosystem.

[enragedcacti]

Double leading underscore has a special meaning and causes the name to be mangled in order to avoid collisions with other classes e.g. `__foo` -> `_ClassName_foo`

https://peps.python.org/pep-0008/#descriptive-naming-styles

[shadowgovt]

Those are the exception that proves the rule. And they basically make those scientific computation libraries Python's equivalent to Boost... Not part of the standard library, but it might as well be.

But in general, Joe Random Developer's library is not that important to justify nibbling away at a function namespace that has no mechanism for keeping two libraries from choosing the same name with different semantic meaning.

[jonathrg]

Those libraries should not have named the methods like that. They could have chosen any naming scheme and they went with something that collides with the only naming scheme available to Python itself

[jimbokun]

Do those tie into Python syntax conventions? That seems to be the over riding theme of the dunder methods in the article.

If not, dunder methods do not seem appropriate.

[anamexis]

Why is it important that those functions use the double underscore naming convention?

[akvadrako]

You get the same benefit without the chance of collision with runtime-level names if you use single underscores like _array, _array_func, etc.

[hobs]

This is definitely bad advice and goes against the python data model. As far as I am concerned, dunder methods are key to idiomatic python.

[TomBombadildoze]

No, it is bad advice, and it is absolutely not idiomatic Python. The language specification reserves them to ensure new ones can be added in the future.

https://docs.python.org/3/reference/lexical_analysis.html#re...

This has been in the specification since, at latest, Python 2.0, and perhaps earlier.

Any you see defined outside the Python data model are entirely historical, written in contradiction to the spec. Many of them also can't be changed because there is so much code in the wild that depends on them.

*Do not define your own dunder methods!*

[agency]

Yeah it seems like a common pattern for custom protocols, like the proposed DataFrame interchange protocol[1] which uses a __dataframe__ method

[1] https://data-apis.org/dataframe-protocol/latest/