Global variables vs. class-based variables in python

А под классовой переменной понимается статический член класса? Поскольку список изменяемый объект то пофигу, но со статическим членом меньше шансов поиметь конфликт имен.

Отдельный модуль, который парсит настройки/предоставляет доступ к настройкам и переменным?

А под классовой переменной понимается статический член класса?

Ага.

class A(object):
    objlist = []

Flat is better than nested. Вобще не понимаю какой профит может быть с class-variable. Все предположения о логичней - не очевидны.

Возможно существует еще какой-либо способ?

О да.

class GlobalVars:
  def __init__(self):
  def do_something(self, ...):

g = GlobalVars()
do_something = lambda g = g: g.do_something(...)
del g
del GlobalVars

Теперь до твоих глобалов никто не доберется в обход do_something :)

Отдельный модуль, который парсит настройки/предоставляет доступ к настройкам и переменным?

В том числе и, но в данном случае список размерностей и единиц измерения в библиотеке для их (единиц) автоматического конвертирования.

Акромя удобства работы с неизменяемыми объектами и исключения потенциальных конфликтов имен - никаких.

Это реально кто-то использует или так, гимнастика для ума?

Про первое не понял, если второе про from foo import *, то ССЗБ. Как бы неймспейс модуля ничем от неймспейса класса не отличается, если не нужно порождать экземпляры класса.

На самом деле они доступны через g.co_func... и т.д.

Это шутка. Но работать будет и это единственный способ инкапсуляции глобальных переменных в Python.

Про первое:

#var.py
a = 1
...
#foo.py
from var import *
a = 2 #угадайте, чему равняется var.a?

На самом деле они доступны через g.co_func... и т.д.

g? Она недоступна.

Если под инкапсуляцией понимается «закрыть от прямого доступа/разрешить доступ только через методы», то в питоне это в принципе не возможно;-)

Отрубать руки очевидно же :)

Это был мой вариант решения проблемы ;) Таким образом решаем, как минимум, возможные конфликты в global(), ибо они все принадлежат модулю.

Тьфу, через поля do_somthing

Гы. Но тем не менее:

#var.py
a = [1,2,3]
...
#foo.py
from var import *
a[:] = [4,5,6]

Это питон... это ладно, со значениями аргументов по умолчанию, и с аргументами во вложенных ф-ях - вот где трэш, угар и содомия.

через поля do_somthing

Конкретное поле?

sys.exit() тоже можно первым стейтментом в модуле написать, но зачем?

>>> f = lambda s='qwerty' : 123
>>> f.func_defaults
('qwerty',)

Ваш К.О.;-)

Даже и не знаю что ответить... а какая связь между sys.exit() и обсуждаемой проблемой? ССЗБ не ответ.

Все сильно зависит от задачи, есть ситуации когда стат член класса (особенно если класс имеет какой-то функционал) удобней обычной глобальной переменной. И даже если не имеет - выделять отдельный модуль под 3 переменных это ИМНО перебор.

Ну я не знаю, я вот просто не помню когда код с вайлдкард импортами видел в последний раз. Может года три назад. От конфликта имен для всех случаев класс все равно не спасет. Я бы выделил модуль, но, даже если его не выделять и ложить рядом с чем то еще, менее неймспейсом модуль сам по себе от этого не становится.

не помню когда код с вайлдкард импортами видел в последний раз.

Только вот не надо из питона делать вижуал бейсик, когда для доступа к переменной надо написать выражение на полстроки с пятью точками;-)

Ну так а кто мешает from foo import bar [as bar2]

А чем это отличается от * (и __all__ в импортируемом модуле) с т.з. глобальных переменных? Ну кроме того что много букв писать приходиться?;-)

Тем что мне в коде потом очевидно откуда этот символ? Ну и еще тем что после апдейта зависимости не вылазят ошибки с конфликтом имен.

А чем это отличается от *

Конфликт имен очевиднее.

Ок, уговорили. Но я все равно для этого слишком ленив;-)

про singleton еще никто не вспоминал?