I've encountered this error when I was:

        self._configs = Dynaconf(
            settings_files=[self.config_folder / '*.toml'],
            validators=self._validators,
            environments=True,
            env=['test', 'dev'],
            envvar_prefix='ATM',
            env_switcher='ATM_ENV',
        )

The error was:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/demo/Live-usb-storage/projects/python/real_alpha/lib/python3.12/site-packages/dynaconf/base.py", line 122, in __getattr__
    self._setup()
  File "/home/demo/Live-usb-storage/projects/python/real_alpha/lib/python3.12/site-packages/dynaconf/base.py", line 183, in _setup
    self._wrapped = self._wrapper_class(
                    ^^^^^^^^^^^^^^^^^^^^
  File "/home/demo/Live-usb-storage/projects/python/real_alpha/lib/python3.12/site-packages/dynaconf/base.py", line 273, in __init__
    self.execute_loaders()
  File "/home/demo/Live-usb-storage/projects/python/real_alpha/lib/python3.12/site-packages/dynaconf/base.py", line 1184, in execute_loaders
    env = (env or self.current_env).upper()
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'upper'

setting env to string 'test, dev' would not work either as dynaconf picked it up as env called 'test,dev'.

I am very new to dynaconf so I didn't raise this as an bug in case I missed something.

I read this as well in the documentation:

Does "will activate both environments" indicate that both settings are going to be available during runtime and we can switch env by setenv, from_env, using_env? I see in the code for the current_env getter, the code is doing load_envs[-1], so I am under the impression that the activated environment will be LIFO, not both, but we do have both environments loaded.

And, it seems to me, please correct me if I am wrong, that environments=True and env='dev' would in effect result in the same state as env=['test', 'dev']: in both cases we have two environments loaded and we have dev activated as the one we can directly access without doing from_env, using_env. If this is the case, do we still need the feature of understanding list for env argument?

Turning on environments and let dynaconf know I want dev to be activated by saying env='dev', is very articulate and clear.

As a new user to dynaconf , I was under the impression that by using the constructor with environments=True, I'd be loaded with environments with custom names I set in my toml files, i.e., [dev.some.value] and [test.some.value] would be picked up correctly as two envs called dev and test.

However, without setting both environments and env together, the environment picked up got defaulted to DEVELOPMENT which was the default by dynaconf. Under env we have this line,

Probably we should rephrase it to that env has to be set if environments is True whilst your have custom environment names?