якщо порівнювати коней та хом’ячків, не зовсім логічно очикувати що великий хом’ячок буде більшим за маленького коня. бо «великий-маленький» відносно для виду
так само і тут, в динамічних мов є своє розділення на «строга/не строга»

дякую і за ваші коментарі, але не відчуваю себе достатнім авторитетом щоб оскаржувати термін, який є хочаб більш-меньш загальним

Дякую за зауваження, але я точно не хочу додавати зайві сутності. uk.wikipedia.org/wiki/Обробка_винятків

ну del та pop — роблять різні речі. конструктор list() зазвичай використовується тільки для перетворення, використовувати його замість літералу — дивна ідея
звісно, є певне дублювання, і легасі нікуди не діти, але в цілому команда Python намагається тримати це під контролем

да якось знайшов, і років 6 працював без NumPy та його друзяк. може тому що більшість бекенду це «дістати з бази, обробити, віддати» а не молотіння виликих багатовимірних таблиць
а більшість складнощів накшталт «чомусь монга рассинхрозувалася з еластиком»
а до NumPy дішов вже тоді коли нам знадобилося рекомендації робити

«а для чого тоді Wnidows, якщо не використовувати WinAmp?»
обчислення — часте використання Python, але це ніяк не робить NumPy та інше — частиною власне мови
а взагалі, люди на пайтоні пишуть бекенд, скрипти автоматизації, десктоп, тощо

я перепрошую, але стороні бібліотеки, навіть такі популярні як NumPy/Pandas/etc. не відносяться до безпосередньо Python як мови, про що ми говоримо. Це як обговорювати дизайн Віндовс, спираючись на WinAmp

ось з цим якраз в Python зазвичай намагаються боротися «має бути один та тільки один спосіб зробити це»

дякую, слеш подвоївся через те що текст кілька разів проходив шлях з маркдауну в інші формати і у зворотній бік, і десь його додатково екранувало

Ну, тут залежить від досвіду. Якщо не розуміти як працюють higher order functions, може бути складно з декораторами (три рівні вкладеності і усе таке). Але якщо це розуміти, проблем не буде
Мені знадобилися певні зусилля щоб зрозуміти логіку дескрипторів або метапрограмування. Хоча це не те щоб особливо важко. Цікавіше що за багато років це не знадобилося яж ніяк
Ті самі дженерики та усілякі констрейнти у Свіфті потребують більше ментальних зусиль, але використовются набагато частіше

Тому я в цілому теж не особливо розумію що в пайтоні важкого, окрім глибин, які можуть і не знадобитися

ну, побачимо як в мене виходитиме далі розповідати :)

ну от я знаю, бо починав ще в 90-ті (хто пам’ятає що таке TechHelp) і що це мені наразі дає? НІЧОГО окрім теплого відчуття гордості за те що я такий в мами розумник. але мені вистачає розуміння що новачку і так складно, а якщо ще й «розуміти як працює комп’ютер»...

Plain C: масиви, вказівники, функції, усе

менеджмент пам’яті, краши чрез це, перхід за гранцию масива, жах від синтаксису вказівника на функцію, відсутність ООП, неможливість нормально моделювати типи даних... чудова мова для новачка, так

щоб принизити конкурентів?

ні, щоб віднізняти різний підхід

Щодо арифметики із bool, а також концепції «falsy» зачень мені теж не подобається. але свого часу PEP який робив ці операції більш контрольованими — було відкинуто голосуванням. То ж більшість вирішила що їм ліньки писати if len(some_list) == 0:
А щодо навчання, я не знаю якоїсь мови яка б не мала глибини. Питання тільки в тому, наскільки в неї треба занурюватися

Дуже дякую вам за коментарі, але ж в школі ми вивчаємо з початку аріфметику, а не теорію категорій. Так і тут, для навчання багато що із знань буде зайвим. «Строгість» Python полягає в тому що є певний набір правил, які не дозволяють «не осмислено» робити маячню накшталт додавання рядка та числа, або конверсіі з float в int. І в цілому цього розуміння «строгості» достатньо і для навчання і у більшості випадків і потім

Дякую за коментар. В моєму розумінні «базовий курс» має бути відносно стислим та не дуже відходити «в глибину». Бо для тих хто тільки починає вчити програмування — це заскладні данні, а для досвічених розробників зрозуміло, що мається на увазі друге значення, бо у переважній більшості динамічних інтерпретованих мов програмування типи даних у першому значенні — взагалі «не мають значення», якщо не лізти в глибину інтерпретатора

Надо подрочиться, поставить какой-то эмуль

не надо ;)

В начале 2021 года у меня в конторе прямо вой стоял, что дядя купил себе м1 комп, а проект на нем не поднимался)))

ну, за год явно лучше всё стало

Зачем было с неё уходить?

ну, тут причин масса, начиная с плохого соотношения производительности к энергии и заканчивая разными там meltdown и spectre

На телефонах были и блекберри и палмОс и симбиан и еще много-много таких операционок, которые в итоге сдохли

вот что-то мне подсказывает что macOS явно не «сдохнет». да и переезд фактически можно считать завершённым

А х86 совместимые компы были в восьмидесятых и есть до сих пор. Весь интернет, все сервера на них.

даже не знаю, рассказывать вам про Graviton или не надо...

И будут в будущем тоже, не на м1 обрезок же им переехать и потерять совместимость со всем софтварным легаси десятилетий?

и что же такого в М1 «обрезкового»? вполне себе современный проц, не говоря уже про новые ревизии
но как показала практика (тот же Graviton как пример), вполне себе забивают на «софтверное легаси десятилетий» и на серверах. выгодно когда у тебя кратно уменьшается энергопотребление и нагрев. не для всех подходит, но для многих — весьма ок

А с выходом м1 проца обрубить совместимость с приложениями под интел

а что, Rosetta2 уже отменили? не идеально работает, но вполне ОК
в эпоху «экспериментов с powerpc» насколько я помню так же использовали Rosetta, только первую

а вообще — есть какой-то иной способ сменить архитектуру процессоров?

Наверно, эпоха интела на макоси — это временное и несвойственное эпплу, а жаль, было круто.

ну да, теперь больше времени работы с меньшим размером устройства и без рёва вентиляторов — это не круто

все ще ні...

дякую