shurshur

Весь смысл наследования в том, что экземпляр класса B можно использовать и как экземпляр класса A (но не наоборот). Если из B удалить какой-то атрибут, то что будет с наследованием? Если просто пытаться его как-то скрыть, то это не поможет - ведь можно приведением типов экземпляр класса B превратить в экземпляр класса A и получить обратно свой доступ к нужному полю.

И вообще, вот, например, есть библиотека, которая умеет работать с объектами класса A. Библиотека скомпилирована кем-то, её исходный код недоступен. Мы определяем класс-потомок B и далее используем функции библиотеки на объектах этого класса. Всё хорошо, но мы уже не можем запретить библиотеке работать с этим полем.

PS: В своё время намного лучше понять ООП мне помогло чтение описания внутреннего устройства классов в Turborland Pascal. Устроены классы (в Pascal они называются объектами, но это не столь важно) примерно так:

1. Ссылка на таблицу виртуальных методов (VMT)
2. Поле 1.
3. Поле 2.
...

VMT устроена так:

1. Ссылка на метод 1
2. Ссылка на метод 2
...

Наследуемый класс отличается от исходного тем, что у него более длинный список полей (но все поля исходного имеются в наличии и находятся по тем же самым смещениям), а также отличаются адреса переопределённых методов, плюс сама таблица VMT может быть длинее за счёт добавленных новых методов (но те же самые старые методы находятся по тем же смещениям).

За счёт этого даже уже ранее скомпилированный код, ничего не знающий о наследуемых классах, работает с ними как со своими родными.

Телеграм кэширует preview ссылок. Поэтому бесполезно менять что-то на сайте, когда он уже запомнил не то, что нужно.

Решение: находим бота WebpageBot, вводим ему ссылку - и он обновляет preview на серверах Телеграма. Только что проделал это с указанной ссылкой - и всё заработало.

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

Например, мне известен совсем недавний случай, когда одна крупная международная компания (представленная и в России), производящая продукты питания и использующая некоторый зарегистрированный бренд из двух слов, потеряла домен первое_слово.company из-за того, что оно само по себе было чьим-то товарным знаком. При этом указанная компания могла бы зарегистрировать в _некоторых_ странах этот товарный знак и всё равно потерять домен по причине невладения таким товарным знаком в США.

Аналогично может пострадать и Сбер, если домен с его названием будет зарегистрирован в юрисдикции, где у него нет товарного знака. В каком-нибудь Вьетнаме, например. Кстати, вьетнамские домены sber.vn и sberbank.vn свободны (наверняка в домене vn есть ограничения на регистрацию нерезидентами), а индонезийские sber.id и sberbank.id захвачены известным российским киберсквоттером.

Также можно вспомнить, что в нулевые годы гугл долго не мог заполучить gmail.ru и google.ru, поэтому был вынужден ютиться в домене google.com.ru.

Так что нет универсального ответа на этот вопрос. Если найдётся свободный домен, похожий на чей-то, то иногда может и прокатить. Но если домен будет не просто простаивать, а использоваться по отношению к тому же самому Сберу и хоть сколько-нибудь заметен, то ему это вряд ли понравится, а уж в США у Сбера вполне может найтись давно зарегистрированный товарный знак в качестве инструмента давления.

Смотрим в сторону модуля json

import json

data = json.loads(dirtyJson)
print (data["foo"]["bar"][666])

Можно вот так сделать:

math.floor(balance*100)/100

viber://chat?number=%2B79123456789

К сожалению, у Viber всё плохо с нормальным документально обоснованным форматом ссылок, и раньше уже переставали работать некоторые из них, например, viber://contacts больше не работает.

Есть документация по deep link для ссылок на Public Accounts. Есть также такие официальные:

viber://keypad?number=%2Bxxxxxx - открывает номеронабиратель Viber с этим номером
viber://chat?service=xxxxxx - ссылка на Viber Service
viber://more/qr - открывает QR-сканер

Владелец файла неважен, важно наличие доступа. Если доступа на чтение нет, то это всё, приехали.

Так-то кратчайший вариант тут указали:

echo `<-text.txt-`

Но я думаю пользователя волновал именно минус в имени, а не наличие cat, и вот с этим побороться легко:

cat -- -text.txt-
cat ./-text.txt-

Вопрос в такой форме в принципе не очень корректен. Понятно, что vim может намного больше и намного круче, чем nano, но в конкретной ситуации важно не то, насколько крут используемый инструмент, а твоё личное умение решать задачи.

Кто-то может быть и хорошо шпарит всякие клёвые штуки на vim, но элементарные задачи будет решать бездумными копипастами со Stackoverflow, чреватыми получением какого угодно (вплоть до деструктивного) результата. А в это же самое время опытный админ типа одного моего хорошего знакомого быстро и эффективно решит все проблемы в малоизвестном нынче, но весьма популярном лет 20 назад среди пересевших с DOS на UNIX редакторе joe. Ничего предосудительного в этом нет.

Это точно один и тот же файл? Можно сделать stat на файл в системе и отдельно в контейнере, зайдя в него по docker exec. Если inode у файла разный - это разные файлы. Возможно, с пробросом в докер что-то напутано.

Как называется пользователь зависит от содержимого файла /etc/passwd, который в контейнере и на хосте разные. Пользователь в Linux идентифицируется по uid - это просто числовой идентификатор. Соответственно, uid=0 это root, теоретически его можно переименовать, но так никто не делает.

Всё нормально, на /dev/md# и не должно быть таблицы разделов. Почему возникла мысль, что что-то не так?

Если речь идёт о сервисах, продающих за 200 рублей в месяц и подключающих за один день - это всё имитации WhatsApp Web. Легальный WhatsApp Business API стоит дороже и подключают его порой по 2-3 недели (из-за модерации на стороне Facebook).

Указанные два относятся к категории имитаторов Web и это вовсе не скрывают. Но второй более известный и хотя бы предоставляется в России от имени ИП, первый же имеет явно кликбейтовое название, никаких реквизитов владельцев нет, плюс из контактов на сайте только телеграм-бот, короче, я бы поостерёгся. В любом случае, Важный и Ценный Аккаунт, Который Нельзя Поменять я бы не стал отдавать в подобные сервисы, поскольку в случае бана он будет потерян.

Поставщиков имеет смысл выбирать в первую очередь по признаку наличия интеграции под нужную CRM.

В Windows используется COMPOSE_PATH_SEPARATOR=';', но это можно переопределить через env.

Кроме того, в Windows компоненты пути разделяются обратным слешом, поэтому в данном случае docker-compose решил, что в COMPOSE_FILE одно имя файла, лежащего в текущем каталоге.

Википедия, в отличие от большинства сайтов, не ставит задачу сокрытия данных от использования. Кроме её парсинга полезно рассмотреть альтернативные способы:

1. Парсинг дампов SAX-парсером: https://dumps.wikimedia.org/ruwiki/latest/

Главное в тексте находить нужные категории.

2. Использование SPARQL к Wikidata: https://query.wikidata.org/

Например, я наскоро набросал такой запрос, находящий все элементы субклассов "животное":

select ?animal ?animalLabel where {
# субкласс (wdt:P729) животного (wd:Q729)
  ?animal wdt:P279 ?animalSubClass.
  ?animalSubClass wdt:P279* wd:Q729.
  SERVICE wikibase:label { bd:serviceParam wikibase:language "ru,en". }
}

К сожалению, не всегда данные в Википедии хорошо размечены семантически, поэтому в подобную выборку может попасть не всё. Ну и полно будет извлечено из enwiki.