`Settings` behave unexpectedly: me or bug?

[Hibou57]

I encountered a vicious bug, where a plug‑in behaved differently depending on it being reloaded or initially loaded.

Say one have this at the top level of a test plug‑in (that is, executed when the module is loaded):

PREFERENCES = sublime.load_settings("Preferences.sublime-settings")
print(PREFERENCES.has("color_scheme"))
print(PREFERENCES.get("color_scheme", "foo"))

What is it expected to print to the console?

Actually for me and it is loaded as ST starts up, it prints False and None, but if the plug‑in is reloaded it prints True and <some-color-scheme>.

Is this the expected behavior or is it me not understanding how it should behave?

May be that’s just the plug‑in which is loaded before the setting. But if I repeat the second and third line in the run method of a plug‑in, I still get the same. However, if I also repeate the first line in run, I get the expected result.

API Reference (sublimetext.com) says:

load_settings(base_name) Settings Loads the named settings. The name should include a file name and extension, but not a path. The packages will be searched for files matching the base name, and the results will be collated into the settings object. Subsequent calls to load_settings with the name base_name will return the same object, and not load the settings from disk again.

So this should not change anything, if PREFERENCES is initialized while the module loads or when run is executed, this should be the same object, and its methods should return the same when run is executed.

Then, there is something about get:

get(name, default) value Returns the named setting, or default if it’s not defined.

But in the third line, is does not return "foo", it returns None.

I feel lost, and wonder if these two unexpected behaviors (unexpected to me), are two bugs or if it’s me who doing something wrong.

I just fixed my plug‑in about it: it was working fine while I was developing it, because I was constantly triggering a reload while editing it, but it stopped working as expected as soon as I only used normally as just loaded with ST, not reloaded later.

[FichteFoll]

I can confirm that I (and facelessuser too, iirc) have also had this problem before. I do not remember when or why though, just that settings would sometimes be “just None” – especially default settings –, although nothing seems to indicate why that was the case.

[sapphirehamster]

Unless I’m misunderstanding you, you should not call API functions from the top-level. Behavior is undefined.

At importing time, plugins may not call any API functions, with the exception of sublime.version(), sublime.platform(), sublime.architecture() and sublime.channel().

[FichteFoll]

Unless I’m misunderstanding you, you should not call API functions from the top-level. Behavior is undefined.

Likely a misunderstanding. If the API was still unavailable, sublime.load_settings() would just return None and the following line would raise an AttributeError exception. At least from my experience.

[Hibou57]

[quote=“sapphirehamster”]Unless I’m misunderstanding you, you should not call API functions from the top-level. Behavior is undefined.

At importing time, plugins may not call any API functions, with the exception of sublime.version(), sublime.platform(), sublime.architecture() and sublime.channel().

[/quote]

I overlooked that, thanks!

The page you quoted adds just next:
API Reference (sublimetext.com)

If a plugin defines a module level function plugin_loaded(), this will be called when the API is ready to use.

If only I’ve spent a bit more time at the top of this page…

Likely a misunderstanding. If the API was still unavailable, sublime.load_settings() would just return None and the following line would raise an AttributeError exception. At least from my experience.

I would say you are both right: you, because raising an error would be a more appropriate behavior, and SapphireHamster, because the API documentation say so.

— Edit —

Checked: defining a plugin_loaded() to initialize globals, works like a charm.