До сильного ИИ нам еще очень и очень далеко. Сейчас нужно коцентрироваться на проблемах именно слабого, потому что он внедряется с огромно скоростью. Так что сравнение с автомобилем и электиричеством, думаю, уместнее.
Количество пользователей языка ничего не говорил о нормальности. Анекдот про мух знаете :)
Нормальность языка можно и нужно оценивать только в контексте поставленных задач.
И где вы нашли, что я написал, что язык плохой?
И таки да для разработки больших и сложных систем, где работает пара десятков программистов из разных отделов, я выберу и выбираю .net c джавой, жаль что Delphi помер.
Нормальный это безусловно понятие субъективное. Для меня нормальным языком является тот, который не порождает двоякости трактования, и который запрещает делать то, что не разрешено. По своему опыту знаю, что если при разработке системы классов что-то не скрыто — это позже будет использовано и самым извращенным способом.
Да, если начать разбираться с namespace и dict, то становится примерно понятно как и почему так оно все работает. Хотелось бы чтобы подобное, на мой взгляд нетипичное поведение, было бы описано более четко.
При наследовании атрибуты не меняют сущности — они как были свойствами объекта так и остаются. В данном случае происходит завуалированная подмена, причем не описанная в документации.
1. Вам все равно нужно знать какой это атрибут, чтобы случайно не присвоить ему что-либо, и не попасть в ситуацию мной описанную. И я совсем не против читаемости, но не в ущерб «безопасности»
2. Я ожидаю того, что описано в документации — изменения значения атрибута у всех инстансов, как это происходит при обращении через __class__
Никто и не ожидает, что все будет также. Просто некоторые моменты никак не ожидаешь.
Не могли бы вы указать на вводный мануал, где подобное поведение описывается, я пересмотрел штуки три и нигде явно этого не было.
Когда речь идет о серьезных объемах, и количестве связей — визард не прокатывает. bulk insert работает на порядки быстрее. И плюс миграция один в один очень редкое занятие- всегда есть хоть какая-то трансформация. Для этого, как правило создается отдельное приложение или несколько, которые в несколько этапов закачивают данные. И как уже сказал, констрейнты на этот период отключают.
Достаточно спорно нынче стало все это.
1. Проверка бизнес целостности на уровне БД при eventually consistent подходе невозможна, да и ссылочная тоже.
2. При миграции большого кол-ва данных все constraints отключают для скорости и непрерывности процесса. А проверку проводят при подготовке данных.
3. Тут как всегда панацеи нет — что-то должно быть реализовано на уровне БД, что-то на уровне контроллера. Но и размазывать логику тоже не хочется, поэтому все чаще и чаще логика переносится на котроллер
Принципа абстракции.
Если определять язык программирования объектно ориентированным только по наличию конструкций для создания классов, объектов — то да. Только вот чем класс в Питоне отличается от просто контейнера, в который можно напихать что угодно?
Пожалуста, но covariate и covariant опять же разные слова и имеют разный смысл.
Меня T9 поравил в моем первом комментарии: должно быть "… то и получается covariate shift, но не covariance shift."
«Issue» как правило несет отрицательный оттенок, лучше будет использовать items
let’s start by having a look at the items on our agenda
Нормальность языка можно и нужно оценивать только в контексте поставленных задач.
И где вы нашли, что я написал, что язык плохой?
И таки да для разработки больших и сложных систем, где работает пара десятков программистов из разных отделов, я выберу и выбираю .net c джавой, жаль что Delphi помер.
2. Я ожидаю того, что описано в документации — изменения значения атрибута у всех инстансов, как это происходит при обращении через __class__
Не могли бы вы указать на вводный мануал, где подобное поведение описывается, я пересмотрел штуки три и нигде явно этого не было.
2.
Наверное формулировки однозначны, а не «не имеют значения»
Достаточно спорно нынче стало все это.
1. Проверка бизнес целостности на уровне БД при eventually consistent подходе невозможна, да и ссылочная тоже.
2. При миграции большого кол-ва данных все constraints отключают для скорости и непрерывности процесса. А проверку проводят при подготовке данных.
3. Тут как всегда панацеи нет — что-то должно быть реализовано на уровне БД, что-то на уровне контроллера. Но и размазывать логику тоже не хочется, поэтому все чаще и чаще логика переносится на котроллер
Не совсем понятно, что значит возможна аугментация?
Вообще-то это не матрица, попробуйте ее транспонировать, например. Даже если вы ее правильно создатите
A = numpy.array([1, 2, 3, 4, 5, 6, 7, 8, 9])
Если определять язык программирования объектно ориентированным только по наличию конструкций для создания классов, объектов — то да. Только вот чем класс в Питоне отличается от просто контейнера, в который можно напихать что угодно?
Меня T9 поравил в моем первом комментарии: должно быть "… то и получается covariate shift, но не covariance shift."