gwidion - Network

Is there anything more hideous than MacOS file dialog? seriously??

Is there anything more hideous than MacOS file dialog?

seriously??

as personalidades/vozes do Gemini no android: tudo nome de Changemen!! Espero que Tokyo fique bem.

as personalidades/vozes do Gemini no android: tudo nome de Changemen!! Espero que Tokyo fique bem.

Amend: the parent toot is a continuation from this: https://floss.social/@gwidion/114207396394711285

Amend: the parent toot is a continuation from this: https://floss.social/@gwidion/114207396394711285

I think those cover most "_" uses with book-level depth.DM for a certificate if you want. :-)

I think those cover most "_" uses with book-level depth.

DM for a certificate if you want. :-)

... could implement a name that would clash with yours.If you use a single-underscore-sandwich , your intention is passed clearly as...

... could implement a name that would clash with yours.

If you use a single-underscore-sandwich , your intention is passed clearly as something like "this is a mechanism used by this tool, but you may (or may even be required to) declare your own to make use of it - unlike a single "_" prefix which states "do not use this".

The idea is the same as the dunder, but the name is to be used by that tool.An example is `ctypes.Structure` class which requires subclasses...

The idea is the same as the dunder, but the name is to be used by that tool.

An example is `ctypes.Structure` class which requires subclasses to have a `_fields_` attribute

The language docs disincentive one to create new dunder names - even though they will work just as normal attributes if it is not a name defined in the language. (SQLAlchemy, for example, use `__tablename__` for its own purposes).

The idea behind the "don't do your dunders" advice is that someday, a future Python ...

11) (The last ne I remember, really)FInally, some classes and methods do use a single `_` sandwich, like, one single underscore before and...

11) (The last ne I remember, really)

FInally, some classes and methods do use a single `_` sandwich, like, one single underscore before and after an attribute name:

That usually means the tool that is being used along with that class use that name in an special way, but it is _intended_ to be declared by the user (normally one writing a class inheriting from a base class) .

(for example, prefer `gettattr(myobject, "attr")`, and not `myobject.__getattribute__("attr") ` when reaching a...

(for example, prefer `gettattr(myobject, "attr")`, and not `myobject.__getattribute__("attr") ` when reaching a dynamically named attribute - but on the other hand, there is no alternative to accessing an objects` `__qualname__` attribute.

And also, SOME of the names are _meant_ to be read, with no helper built-in - like a module's `__name__` variableSo, the idea above...

And also, SOME of the names are _meant_ to be read, with no helper built-in - like a module's `__name__` variable

So, the idea above about preferring not using dunder names directly is by no ways a RULE - just a strong preference when _There_ is a builtiin or other obvious call to do the job.

But when WRITING your classes, you can and SHOULD use the appropriate dunder methods. If the object type your are implementing can be...

But when WRITING your classes, you can and SHOULD use the appropriate dunder methods.

If the object type your are implementing can be meaningfully added with other objects, _do_ add an `__add__` method.

If it has a meaninful length, define a `__len__` method , and don't use some ".length" arbitrary attribute: in that way your instances will work natively with Python operators and protocols.

So, when _Calling_ things, like, when you want an instance's length in the case of a container, you should prefer calling...

So, when _Calling_ things, like, when you want an instance's length in the case of a container, you should prefer calling `len(myinstance)` than calling directly `myinstance.__len__` - the later will work, but the `len` call (which is more like an operator than an ordinary function) should always be preferred, as it might offer fallbacks for some cases. (The `for` statement will try `__iter__` and them fallback to `__getiem__` on an instance, for example) ...

The concept of special dunder names is not restricted to class level attribute or method names: Python modules have some varibales created...

The concept of special dunder names is not restricted to class level attribute or method names:

Python modules have some varibales created automatically and always available (such as `__file__ ` ) , and there is a naming convention for files - mainly `__init__.py` and `__main__.py` - with the same idea: these are the names Python will itself fill in, call, or import in your code.

One important thing is: a name being a dunder DOES NOT MEAN it is private, or that it should not be used!

I give emphasis to: the thing special about these is that Python will itself call your method (or read your value) and use it for...

I give emphasis to: the thing special about these is that Python will itself call your method (or read your value) and use it for itself.

There are more than 100 names prefixed and postfixed with double `__` like `__slots__`, `__add__` , `__new__` - most of which are documented in the "Data Model" Python documentation page: https://docs.python.org/3/reference/datamodel.html

10) And finally (ok, I may be forgetting one or two cases) - there are the "dunder' methods - names like `__this__`: both prefixed...

10) And finally (ok, I may be forgetting one or two cases) - there are the "dunder' methods - names like `__this__`: both prefixed and suffixed with two `__` . Among Pythonistas, these are usually referred to as "dunder" names .

These are names RESERVED BY THE LANGUAGE SPECIFICATION for attributes and methods that will be used/called by the language itself.

The most famous of them is `__init__` everyone writing a class should implement (`@dataclass` creates one of those too).

would change them directly, simply mark them with a SINGLE `_` - that should be enough. Two `__` are when the name mangling mechanism might...

would change them directly, simply mark them with a SINGLE `_` - that should be enough.

Two `__` are when the name mangling mechanism might have some utility, not to just delay by a few minutes one who needs to pick data on your class you forgot to write a public interface to .

So, whie there are docs, examples, and even Python books which will regularly use double `__` for any internal attribute or methods in a...

So, whie there are docs, examples, and even Python books which will regularly use double `__` for any internal attribute or methods in a class - it is really not semantically (or Pythonic) correct to do that: it will just hurt your code readability.

Few projects uee an extensive multiple-inheritance hierarchy where that is really useful.

Python idea is to be permissive. If here are attributes or methods which can really spoil some calculations/states if users external to your class...

```In [8]: class A: ...: __b = 1 ...: In [9]: dir(A)Out[9]: ['_A__b',...```Any other use of "b" in the body or in...

```
In [8]: class A:
...: __b = 1
...:

In [9]: dir(A)
Out[9]:
['_A__b',
...
```
Any other use of "b" in the body or in a method defined inside the body `class A` can simply use `self.__b`.

Any code outside that block will "see" the name `_A__b` for the same attribute.

This allows collision free multiple inheritance - mixin classes for which the implementers don't care about their methods should prefix their private attributes with `__`

Not hard to see that this is a RARE case

8) Now about DOUBLE underscores - `__` prefixing an attribute or method name : This only has effect on names used inside a `class` ...

8) Now about DOUBLE underscores - `__` prefixing an attribute or method name :
This only has effect on names used inside a `class` statement block: they will trigger a "name mangling" mechanism when the class statement is executed:

All names prefixed with `__` are further prefixed with `_<class name>`.

This allows the much rarer real use of encapsulation that is to avoid attribute name clashes in complex inheritance hierarchies.

```$ ipythonPython 3.13.2+ experimental free-threading build (heads/3.13:fc1c9f8, Feb 17 2025, 17:58:08) [GCC 14.2.1 20250110 (Red Hat...

```
$ ipython
Python 3.13.2+ experimental free-threading build (heads/3.13:fc1c9f8, Feb 17 2025, 17:58:08) [GCC 14.2.1 20250110 (Red Hat 14.2.1-7)]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.27.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: 2 + 2
Out[1]: 4

In [2]: _ + _
Out[2]: 8

In [3]: _1 + _2
Out[3]: 12

In [4]: # The inputs are kept as strings in similar names (prefixed with `_i` )

In [5]: _i3
Out[5]: '_1 + _2'

```

7) in iPython and other notebooks, this idea is extended with the output of EACH line or cell since the session started being assigned to a...

7) in iPython and other notebooks, this idea is extended with the output of EACH line or cell since the session started being assigned to a variable that is the line number prefixed by "_":