Как понять/выучить ООП Python?

Vitsliputsli, mayton2019 ,обоснуйте пожалуйста свою точку зрения, что не так в python с ООП?

Golang не показывает что структура реализует интерфейс?

Да, вы правы, самая последняя сборка корректно работает с дженериками.

Как лучше учить документацию?

Заметтье, что вы сами написали "Осмысленное". Т.е. вы должны именно понять тему, погрузиться в нее, попробовать как это работает на самом деле. Простое перечитывание того что вы не понимаете ничего не даст, хоть 500 раз прочитай.

Как узнать какая программа отослала пакеты данных?

AUser0, хм. Да, тоже верно.

Как узнать какая программа отослала пакеты данных?

netstat или ss(более современный налог netstat) покажет на каком адресе локально висит процесс. Чтобы отловить пересылку на какой-то адрес нужно очень сильно постараться, т.к. соединения скорее всего после отсылки закрываются сразу и поймать там что-то нереально будет. Тут без wireshark или tcpdump не обойтись

Фундаментальное отличие async await в python и javascript?

stan288, любой async возвращает промис, а await в свою очередь ждет когда промис будет в состоянии fullfiled

Фундаментальное отличие async await в python и javascript?

stan288,

1. Нет, во втором примере не нужно еще раз делать await. Первый await как раз и нужен для того, чтобы дождаться данных из await doReq1(). Если сравнить первый пример и второй, то console.log(res.data) будет исполнен как будто бы в then блоке, т.е. после того как Promise примет состояние fullfiled. Т.е. нужно понимать,что await блокирует дальнейшее исполнение. Если вам в main не нужно блокировать основной поток исполнения, то тогда нужно перенести обработку данных из doReq1 в саму эту функцию, как на примере ниже.
   
2. Согласно пункту 1 - нет, функция не сделает return пока не будет разрешен промис который вернет запрос axios, поскольку мы там указали await. Без await функция вернула бы результат которым оказался бы не разрешенный промис и данные мы бы не успели вывести
   
3. Обязательно. Любая функция делающая await должна иметь async, иначе код даже не запустится.
   

Пример без блокировки main

const axios = require('axios')

async function doReq1(){
    const res = await axios.get('http://localhost:12000?id=1')
    console.log(res.data)
}

async function main(){
    console.log("Before req")
    doReq1()
    console.log('After req')
}

main()

Резюмируя: вам нужно понять, что действительно асинхронно в данном случае исполняется сам запрос внутри axios (он там построен на FatchAPI или XMLHttpRequest, точно не знаю, т.е. API среды исполнения, которая реально в отдельном потоке запустит сетевой запрос). Ваш же код будет исполнен синхронно, только результат из промиса который вернет axios будет исполненин очередью задач после того, как call stack окажется пустым. Рекомендую вам, чтобы это понять попробовать реализовать неблокирующее итерирование через for await, после того как я это сделал ко мне как раз пришло понимание как асинхронность работает.

Нормально ли объединять сущности по паттернам?

Сергей Паньков, вы скорее об SRP говорите я так думаю. Не понятно как пакеты будут подчиняться LSP например.

Как использовать классы через интерфейсы?

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

Как использовать классы через интерфейсы?

mayton2019, не знаю что там в SpringData, но скорее всего да. Я вот о чем: https://martinfowler.com/eaaCatalog/repository.html

Как использовать классы через интерфейсы?

А есть ли там механики полиморфизма - ХЗ.

есть. Странно было бы если бы было наследование, но полиморфизма не было.

Как использовать классы через интерфейсы?

то хороший пример переключения
функционала например с Db MySQL на Postgresql без переписывания бизнес-логики.

Пример как раз не очень хороший. Ни разу на практике не встречал вот чтоб просто РАЗ и переключили БД. Тут упущена целая гора деталей. Просто переключить можно будет с помощью паттерна репозиторий, заменяя источники данных. В target классе который репозиторий использует при этом ничего менять не нужно будет вообще, но репозиторий для другого источника написать придется.

Нормально ли объединять сущности по паттернам?

Сергей Паньков, SOLID здесь каким боком?

Где можно найти задачи для практики ООП?

Как это связано с пониманием обьектной парадигмы?

Сколько ядер процессора хватит для программирования?

Adamos, откуда пошло поверье, что в IDE ты не понимаешь что ты делаешь? Если код для тебя это набор хер пойми каких строк, то он что в блокноте, что в IDE будет хей пойми набором строк, только во втором случае цветных строк.

Может кто-нибудь дать реальную задачу на которой можно применить ООП?

Hemul GM, тут как все в этой парадигме - вопрос холиварный. Но по моему путь к файлу должна содержать абстракция файла. Что вы будете делать с путем файла в обьекте трека? Запись на диск при изменении у вас трек будет производить? Это и есть нарушение абстракции. К тому же название трека и название файла могут различаться, придется в обьекте трека держать сразу два поля

Может кто-нибудь дать реальную задачу на которой можно применить ООП?

Пусть трек будет представлять объект, содержащий путь к файлу,

Если трек как обьект содержит в себе путь к файлу, это нарушение уровня абстракции. Легко сказать "просто реши задачу на ООП". Об этом как раз остальная "фигня" и написана.

Может кто-нибудь дать реальную задачу на которой можно применить ООП?

mayton2019, а никто не говорил, что ООП всегда оправдано. Эта парадигма не на пустом месте появилась, она позволяет моделировать задачу, как собственно и любая другая парадигма, просто на больших обьемах задачи это моделирование оказывается удобнее. То что задачу можно решить разными способами уже говорит о том, что ООП не может быть в чем-то там право. С этого момента уже нужно думать об удобстве для разработчика и бенефитах заказчика и это как раз ООП нам и дает. Для заказчика разработка ведется быстрее и дешевле, за счет код реюза (как реюза внутри проекта, так и библиотек, что тоже кодреюз). Для разработчика такие принципы (практики) ООП как инкапсуляция, абстракция, information hiding, позволяют разгрузить его кошелек Миллера. Смысл как уже я и остальные писали ниже - управление сложностью проекта. И как ООП так и другие парадигмы дают методы и подходы к управлению этой сложностью. Еще раз, ООП это не истина в последней инстанции которая может какую-то правоту чего либо доказать, это попытка в решение проблемы которая стара как мир - декомпозиция сложных систем

Может кто-нибудь дать реальную задачу на которой можно применить ООП?

mayton2019, ООП вроде как и не пыталось в "корректность" и "доказательность" . Это реально набор практик - "делай так и ВОЗМОЖНО станет лучше". Для определения корректности написанного добра есть тесты, мат. моделирование, денотационная семантика, и наверное еще десятки методов. А ООП оно про - "как писать код чтобы его потом можно было поддерживать".

У нас также нет математически верного доказательства правоты ООП

Правоты простите в чем?
Если вас интересует какая-то мат база ООП, можете посмотреть на проект Егора Бугаенко - EOlang. Вроде как это ООП язык основанный на некоем пси исчислении.

Может кто-нибудь дать реальную задачу на которой можно применить ООП?

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