Use of implementation specific behaviour in cases where it could be avoided

[ghost]

Checklist

• I added a descriptive title
• I searched open reports and couldn't find a duplicate

What happened?

There are several cases within the conda program where conda relies on implementation-specific behaviour, and in most of these cases it could be easily avoided with virtually no performance cost.

The implementation-specific behaviour in question is dunders (double-underscored names or attributes). The relevant part of the Python3 documentation states

"System-defined names, informally known as “dunder” names. These names are defined by the interpreter and its implementation (including the standard library)."

There are some cases where the use of these dunders is justified, (i.e., an alternative implementation would be much less performant), but in most instances of dunder use this is simply not the case. For example, obj.__class__ is used where type(obj) could be used instead. Another common example that I've noticed is obj.__dict__, where vars(object) could be used instead. Because dunders are technically implementation defined, there could exist Python implementations which don't support the usage of certain dunders in certain ways, and therefore dunders should be avoided whenever the cost of doing so is negligible (as it is in the examples I have given).

If it's alright, I'll start work on a PR which replaces the use of dunders (where the cost is negligible). If you have any questions, comments, or concerns, please let me know and I'll get back to you as soon as I can.

Conda Info

No response

Conda Config

No response

Conda list

No response

Additional Context

No response

[travishathaway]

Hi @Resuscitating,

Thanks for submitting this issue. While the maintainers of this project agree with you, this level of refactor is not currently a priority for us. Regardless, we are interested to see what you can come up with, so we have assigned you to this issue.

Feel free to ping me directly on this issue if anything comes up while working on this. If you decide for whatever reason that you would like to stop working on this issue, we ask that you close it for us or simply let us know in this issue.

Good luck and thanks for contributing to our project.

[kotnen]

Hey there @travishathaway!

I came across some unneeded dunders in the codebase, and was planning on opening an issue for it when I discovered that this issue already existed. Seeing as the original author of the issue seems to have abandoned this (and has vanished entirely), would it be alright if I took over from them on doing something about this?