pmus

port = 443

def change_port():

‧‧‧‧global port

‧‧‧‧port = 8080

change_port()

Хорошая ли это идея? Автор вопроса пытается вывести нас на шаблонный ответ, что конечно же, это идея плохая (он прав). Вся концепция ООП крутится вокруг иерархии, "кто на ком стоял" и "кому что можно, а что нельзя". Однако существуют случаи, когда проще использовать глобальную переменную, особенно в программе, которую ты пишешь сам от начала до конца.

Они и сами по смыслу являются глобальными, некими общими для всей программы сущностями. Например, при написании программ с GUI на QT у нас имеется одна сущность - окно программы, QMainWindow. Мы можем все эти вещи для работы сделать свойствами написанного нами класса, назовем его MyGUI. Отлично, gui = MyGUI() и теперь инстанс этого класса все равно будет использоваться глобально отовсюду, потому что как у нас было одно QMainWindow, так и осталось.

Хорошая ли это идея? В абстракции - нет, фу-фу-фу, нам нужна иерархия, инкапсуляция и вот это вот всё.

А на практике может случиться, что тебе приходится делать именно вот так и никак иначе. На паттерн "синглтон" вроде бы никто не ругается - есть сценарии, когда он нужен. И с глобальными переменными то же самое. Их следует избегать во всех возможных случаях, а в невозможных - картинно закатить глаза, и написать "global".

Это кросспост из моего Telegram-канала "Не Ван Россум", где я прямо сейчас пишу сериал "101 вопрос про Python" с описанием подводных камней, неочевидностей и загвоздок.

#сериал101, #40

#37 Как сделать python-скрипт исполняемым в различных операционных системах?

Я буду рассматривать этот вопрос в двух разных плоскостях:

1. "Как сделать python-скрипт мультиплатформенным, то есть, работающим и под Windows, и под Linux?"
2. "Как сделать python-скрипт портируемым, то есть переносимым с машины на машину."

В чём разница?

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

Например, правильно выбрать pathlib для работы с путями файловой системы, вместо определения, какие же слэши для путей (os.sep) нам нужны - прямые или обратные.

Не знаю, как сейчас, но psutil долгое время была доступна только для *nix-like систем, потому что работает с встроенным в *nix-системы инструментарием, о чём говорит даже само название: ps - это встроенная команда, доступная например, в Linux, но никак не в Windows.

То есть, мы изначально пишем программу, модуль, функцию, класс с учетом того, что операционная система может отличаться от той, что имеется у разработчика. Соответственно, и тестируем написанный код под разными системами. Для этого можно использовать виртуальное окружение, например, VirtualBox справится с этой задачей.

(это была первая часть).

#сериал101, #37

Это кросспост из моего Telegram-канала "Не Ван Россум", где я прямо сейчас пишу сериал "101 вопрос про Python" с описанием подводных камней, неочевидностей и загвоздок.