Как говорят другие, конечно, это все еще чистая функция.
Однако поговорим о проблемах дизайна. Вы правы, пытаясь сделать что-то, чтобы сохранить код СУХИМ, поместив значение только в одном месте. Кроме того, я думаю, что следует учитывать уровень связи, который является подходящим.
Использование функции дает вам больше гибкости для изменения реализации, то есть функциональный подход предлагает более слабую связь, чем глобальная переменная.
Вопрос в том, нужно ли это кому-то или нет?
Если потребители и поставщик находятся в одном и том же модуле, а поставщик является закрытым для этого модуля, трудно утверждать, что этот уровень слабой связи необходим, поскольку поставщик требует обновления с частной переменной до Частный метод, простой рефакторинг внутри модуля может быть применен к потребителям одновременно. Использование метода / функции до того, как вам действительно понадобится, может попасть в категорию YAGNI.
Даже если потребитель (-и) и поставщик находятся в разных модулях, но модули имеют версии вместе (например, вы используете минимизатор, так что модули потребителей и поставщика находятся в одном файле), также может применяться YAGNI.
С другой стороны, если, например, производитель находится в пакете или модуле библиотеки или API, который имеет версии отдельно от потребителя (ей), то использование этой функции может оказаться целесообразным. В этом случае мы должны смотреть на долговечность API и такие принципы, как OCP.
(С другой стороны, если ваш код имеет значительный размер, я бы рекомендовал использовать модули с полями и методами, а не глобальные переменные и функции.)