Руслан Гильфанов

Пробовал поставить и настроить openbox в качестве менеджера окон, но запарился с конфигами.

Проще оказалось не использовать зависящий от менеджеров окон метод fullscreen():
self.fullscreen()
А получить текущую ширину и высоту дисплея у Gdk.Screen и задать с помощью метода resize():

self.resize(Gdk.Screen.width(), Gdk.Screen.height())

Результат:

Переписал кастомный CardObserver таким образом:

from smartcard.CardConnectionObserver import ConsoleCardConnectionObserver
from smartcard.CardMonitoring import CardObserver
from smartcard.util import toHexString
from smartcard.Exceptions import CardConnectionException, NoCardException
from time import sleep


class CardObserver(CardObserver):
    def __init__(self, app):
        self.app = app
        self.connection_observer = ConsoleCardConnectionObserver()
        self.has_card = False
        self.rfid_tag = None
        self.card = None

    def update(self, observable, actions):
        connected_cards, disconnected_cards = actions
        if connected_cards:
            self.card = connected_cards[0]
            self.get_rfid_tag()

        for card in disconnected_cards:
            self.rfid_tag = None
            self.has_card = False
            self.card = None

    def get_rfid_tag(self):
        try:
            self.card.connection = self.card.createConnection()
            self.card.connection.connect()
            self.card.connection.addObserver(self.connection_observer)
            data, sw1, sw2 = self.card.connection.transmit([255, 202, 0, 0, 0])
            data.reverse()
            self.rfid_tag = toHexString(data, format=1)
            self.has_card = True
        except NoCardException as error:
            print(error)
        except AttributeError as error:
            print(error)
        except CardConnectionException as error:
            print(error)

    def rfid_tag_check_worker(self):
        while True:
            if self.card:
                self.get_rfid_tag()
            sleep(5)

И при запуске приложения, создаю дополнительный поток, вызывающий функцию rfid_tag_check_worker.

rfid_tag_check_thread = Thread(target=self.rfid_card_observer.rfid_tag_check_worker)
rfid_tag_check_thread.start()

Пока вроде работает корректно, хотя к картридеру обращаются два потока.

Потестирую с меньшими интервалами проверки, надеюсь это стабильное в работе решение.

1. Теоретически, антивирус написать можно. Но для более-менее вменяемого антивируса нужны производительность и доступ к более низкоуровневым вещам, чем Python позволяет из коробки.

Многие библиотеки Python -- это обёртки над библиотеками на C/C++. А в коде на C/C++ вообще могут использоваться ассемблерные вставки. В этом смысле, в Python можно прокинуть вызов любого низкоуровневого кода.

Всё, что необходимо для написания антивируса давно должно иметь свободную реализацию на C/C++ и лежать в открытом доступе. Многое уже может иметь обёртки или биндинги для Python, а что не имеет -- так со знанием C/C++ их можно сделать.

Конечная программа на Python может полностью полагаться на скомпилированный Си-шный код, так что производительность будет не намного ниже, а возможности те же.

Основные недостатки разработки настольных программ на Python:

• трудно скрыть исходники от любопытных;
  
• не очень удобно собирать и распространять под разные ОС;
  
• для низкоуровневых вещей и/или высокой производительности может потребоваться знание C/C++.
  

2. Для специалиста по информационной безопасности, Python -- несущественный язык программирования.

Специалист по информационной безопасности должен знать низкоуровневые языки -- ассемблер и Си.

Помимо этого, полезно знать:

• архитектуру ЭВМ (особенно, как работает процессор и оперативная память -- тема пересекается со знанием ассемблера),
  
• архитектуру операционных систем (близко к архитектуре ЭВМ, но тема больше пересекается с языками программирования C/C++),
  
• технологии компьютерных сетей,
  
• алгоритмизацию,
  
• криптографию.
  

Можно. Но преимущественно, в учебных целях.

1) Логичнее писать трояны для программного обеспечения на Python или использующего Python как скриптовой язык для расширений и плагинов.

2) Написание червей теоретически возможно:
- либо червь должен таскать с собой стандартный интерпретатор,
- либо исходники должны быть приведены к эквивалентному коду на C/C++ и скомпилированы (см. python-компилятор Nuitka или язык программирования Cython).

В любом проекте на Python для работы с реляционными СУБД можно использовать ORM SQLAlchemy.

Документация по SQLAlchemy:
docs.sqlalchemy.org/en/latest

Среди дополнительных пакетов SQLAlchemy сходу нагуглил SQLAlchemy-ORM-tree для организации иерархических структур данных в реляционных СУБД. Пакет реализует паттерн Nested Set.

Документация по SQLAlchemy-ORM-tree:
https://sqlalchemy-orm-tree.readthedocs.io/

Установка пакетов через pip (или для Python3 в Linux -- pip3):

pip install SQLAlchemy
pip install sqlalchemy-orm-tree

Ещё чуть поискал, нашёл пакет sqlamp, реализующий другой паттерн хранения иерархических структур данных -- Materialized Path -- для SQLAlchemy.

Документация по sqlamp:
sqlamp.readthedocs.io/en/latest

Но я бы предпочёл SQLAlchemy-ORM-tree, паттерн Nested Set вроде имеет больше преимуществ и меньше недостатков.

Быть может лучше принимать ещё один аргумент при вызове?

class Color:
    def __init__(self):
        self.red = '\033[91m'
        self.green = '\033[92m'
        self.blue = '\033[94m'
        self.cyan = '\033[96m'
        self.white = '\033[97m'
        self.yellow = '\033[93m'
        self.magenta = '\033[95m'
        self.grey = '\033[90m'
        self.black = '\033[90m'
        self.default = '\033[99m'
        self.end_color = '\033[0m'

    def color_print(self, data, color):
        print(getattr(self, color) + data + self.end_color)

obj = Color()
obj.color_print('Текст красного цвета', 'red')
obj.color_print('Текст зелёного цвета', 'green')
obj.color_print('Текст синего цвета', 'blue')

Реализация очень топорная, но как вариант.

Если очень нужно генерировать методы классов в реальном времени, придётся лезть в мета-программирование.

Пример решения схожей задачи: https://stackoverflow.com/questions/13194180/dynam...

Если я правильно понял вопрос, могу ответить так.

Обычно, исходники каждого проекта кладут внутрь папки с виртуальным окружением. Если все ваши проекты находятся в одной папке -- "одноимённые" виртуальные окружения не даст создать файловая система.

Однако, часто делают по-другому. Виртуальные окружения создают внутри папок с проектами, в таком случае все виртуальные окружения обычно "называют" env, а исходники проекта лежат рядом -- в папке src.

Смысл подхода очевиден, в корневой папке каждого проекта у нас в 2 раза меньше папок и файлов. В общем виде так:
- docs -- документация проекта
- env -- виртуальное окружение
- requirements -- папка или файл с зависимостями
- src -- исходный код вашего проекта

Если мы используем Git, то чтобы не включать в репозиторий файлы виртуального окружения, в .gitignore мы прописываем всего лишь одну строку:
env/
Вместо вот этой ереси:

bin/
include/
lib/
lib64
share/
pip-selfcheck.json
pyvenv.cfg

Как недостаток, путь до виртуального окружения на 4 символа длиннее:
source env/bin/activate

В остальном, не вижу особой разницы как называть и где размещать виртуальные окружения. Виртуальное окружение -- это просто папка с настраиваемой Python-песочницей.

Делайте так, как Вам привычнее и/или удобнее.

Я больше знаком с Python экосистемой, поэтому могу быть несправедлив в отношении PHP.

PHP:
- проще с работой
- проще с хостингом
- язык для веб-разработки

Python:
- проще с отладкой кода
- проще с читаемостью кода
- проще с безопасностью кода
- язык общего назначения
- много самых разных библиотек

Производительность обоих языков сопоставима и заметно улучшена как в PHP 7, так и в Python 3.6.

Может проще написать API для интеграции сайтов-партнёров и вашего сервиса?

При добавлении новых товаров, партнёр вручную соотносит их с товарами на вашем сервисе.

А вот все изменения цен, наличия и пр. с сайта-партнёра должны автоматически переносится на ваш сервис. От сайта-партнёра -- запрос на обновление данных, от вашего сервиса -- ответ с подтверждением, что данные обновлены.

Большинство интернет-магазинов используют одни и те же CMS, а значит можно написать и предложить основные плагины для интеграции.

Разработка простого API и написание плагинов кажется более простым и разумным решением, чем собственная поисковая система.

Я не представляю, как не будучи Google`ом или Яндексом упорядочить классический хаос товарных наименований. Разница в 1-2 символа может быть в написании одной модели товара, разных товаров одного модельного ряда и даже у товаров разных производителей (см. китайские бренды, что на 1 букву отличаются от мировых). А ведь может быть ещё проблема неполных наименований, когда остаётся только гадать какой именно товар имелся ввиду.

В общем, я бы пошёл решать задачу с другой стороны -- со стороны партнёров.