Я уже много беседовал на эту тему со свидетелями Священной Big O, и мне довольно-таки надоело, но напишу еще раз тут: для фронтэндера, например, вопрос знания сложности алгоритмов в лучшем случае примерно третий по важности, и на собеседовании особо не значим. Почему? Потому что высокая алгоритмическая производительность на фронтэнде иногда нужна, но весьма редко; а вот знать, как браузер грузит ресурсы и рендерит страницу — нужно практически для любого реального проекта. Быстродействие будет определяться именно этими двумя вещами, а не тем, что вы где-то там внутри дуболомно изобразили O(n!), вот только n всё равно выше десятка не вырастет даже в теории.
Главное, чтобы потом не надо было отобразить табличку, в которой более 100 элементов. А ведь иногда ещё и 1000 может прийти. Очень не каждый выдержит такое. Jira и confluence вот не всегда справляются.
Не раскрыта тема приятности в общении. Человек может ответить на все вопросы и прорешать все задачки, но вот предложения ему не дождаться, потому что запах изо рта, в общении тяжёлый, плохо реагирует на критику (а как тогда его код ревьюить), стесняется критиковать сам (а как тогда он джунов будет учить), а ему ещё в джире надо в тикетах отписывать и на митингах что-то предлагать, и вообще, не хочу я его видеть по 8 часов в офисе рядом с собой.
Мир устроен жестко — или ты вкалываешь жестко первые 20 лет своей жизни во время учёбы и расслабляешься на хорошей работе остаток своей жизни, или ты пинаешь первые 20 лет и расслабляешься как можешь — но зато остаток жизни вкалываешь как проклятый на такой вот работёнке.
Это всё конечно так, особенно в некоторых странах, но в других нет бесплатного обучения в колледже, и ты бы и рад отучиться на адвоката и получать несколько сотен тысяч в год, но приходится вкалывать в фастфуде за несколько десятков. Особенно, если у родителей нет денег оплатить тебе кредит на образование, зато есть счета из больницы, которая не менее платная, чем колледж.
>Модераторы: Подают в суд на ютуб за то что они смотрят неприятный контент
на ютуб?)
Ожидается, что подобные иски подадут десятки, если не сотни, модераторов. Источник из юридической компании Coleman & Partners, работающей на Грея, рассказал нам, что новые документы будут отправлены в Верховный суд в этом месяце.
Думается фейсбук скоро наймёт компанию из Мумбая для модерации вместо компании из Дублина.
автор:
>Ненавистники Python всегда говорят, что Python — это медленно. Но то, что некая программа, независимо от используемого языка программирования, может считаться быстрой или медленной, очень сильно зависит от разработчика, который её написал, от его знаний и от умения создавать оптимизированный и высокопроизводительный код.
он же:
>Дело тут, в основном, в том, что встроенные механизмы языка реализованы средствами C. Если описывать нечто средствами Python — нельзя добиться того же уровня производительности.
Зачем же ограничивать гибкость типов аргументов? В некоторых случаях использование имени параметра вместо его позиции будет бесполезным и неуместным. Ограничение так же позволит избежать проблем, если вы планируете изменить имена позиционных аргументов в будущем.
Некоторые ф-ции из стандартной библиотеки имеют такую сигнатуру, например bool.
Changed in version 3.7: x is now a positional-only parameter.
Что выглядит вполне логичным, действительно, какие имя дать этому параметру? `o`, `x`, `a`?
Создали отдельную сущность, заметим, только в 2016м. Через восемь лет после выхода Python 3.0
Что подтверждает только то, что это не было первостепенной задачей ни для кого. Иначе ввели бы раньше.
Работа с однобайтовыми кодировками банально быстрее, чем с многобайтовыми. А для словаря с одним языков (99% случаев) многобайтовая кодировка не нужна.
Ещё раз, python не про скорость и не работу с бинарными данными, он про читаемость, файл с несколькими кодировками — это не к читаемости. Создатели python не предусматривали такой сценарий, естественно, он в таком формате неоптимален, но люди, смешивающие кодировки, должны страдать.
В тоже время куча людей создаёт сайты на django, тесты и скрипты автоматизации на python и не жалуется.
Зачем вы храните разные кодировки в одном файле?
Потому что так удобнее.
Вы уверенны? Новички, приходящие в вашу команду, как это воспринимают? Интуитивно понятно?
была такая беда в Fedora — всё накрывалось медным тазом из-за того, что строка сообщавщая об успешном завершении установки выбрасывала UnicodeError…
Текст — это сложно. Я про это отписал, как починили по итогу?
Ну и как, я извиняюсь, это может работать? Ни один из предложенных там вариантов не позволит мне сохранить данные после декодирования.
Почему? Вы прочли бинарные данные — перегнали их в текст, обработали — перегнали обратно в бинарные. Можно даже сразу обрабатывать бинарные, `b'my_string'` вам в помощь. Если формат файла более-менее постоянен и позволяет описать их константами.
И вы так и не написали, как реализованы строки в C++.
То, что в них нельзя засунуть произвольную последовательность байт, очевидно. Например вы не можете имя файлы (которое в Windows не обязано быть валидной UTF-16 последовательностью, а в Linux валидной UTF-8 последовательностью) поместить в строку и проверить — не начинается оно с нужного вам префикса.
Это проблемы python или ОС, которые сохраняют имена файлов в чём попало? Строка в python имеет определённую кодировку, вполне логично запретить туда записывать мусор. Для работы с файлами создали отдельный механизм, потому что это отдельная сущность. Зачем ломать из-за этого общий механизм?
Ну и кому и зачем это может быть нужно? Зачем оптимизировать работу под операции которые никогда не используются (или используются исключительно редко) за счёт операций, которые используются часто?
Ну если вам ненужно, очевидно, что всем не нужно. Напишите в почтовую рассылку, просветите заблудшие души.
Есть C, который гораздо лучше подходит под обработку бинарных данных, python вообще не про это.
А про что он вообще тогда?
Про читаемость. Это если одним словом, если несколькими — это к дзену, там про бинарные данные ничего нет.
Никак — ошибка же в дизайне. Остаётся только смириться. Ну вот такой вот бессмысленный высер, который обошёлся индустрии в миллиарды и не дал никакой прибыли. Конструктивно — нужно убрать человека, который его затеял, чтобы больше такого не повторялось.
Опять же, могу только посоветовать написать в рассылку. Кстати, а как вы подсчитали урон? Можете поделиться?
В Python3 любое простое решение «правильно на 99.9%», но вот оставшийся 0.1% — исправить, зачастую, возможно только полными переписываением всей программы. Что дорого и сложно.
Утверждение верное для любой технологии, даже молотка.
Простейший пример, которым я всегда тыкаю в нос — простенький файл для работы со словариком и там буквально пяток функций для каждого языка. Которые просто возвращают список гласных, список согласных и так далее. Для английского, немецкого, польського и русского (там ещё что-то было — но эти ключевые). Функции, работающие с немецким рассчитаны на Latin-1, на польский — на Latin-2, Руссики — windows-1251… ну и комментарии в UTF-8 для удобства.
Всё это, ещё раз повторяю, в одном файле. Инструменты старого образца (Emacs, Far или тот же Python2) — вообще не проблема. Говорим, что это последовательность байт и всё. Что-то сделать в Python3… практически невоможно.
Ну потому что этот текстовый файл в Python3 строку — не лезет. Ну никак.
Это простой пример? Зачем вы храните разные кодировки в одном файле? В чём скрытый смысл? Как вы его обрабатываете сейчас? Чем? Зачем?
С этого момента — поподробнее: как его применять для редактирования подобного файла?
Читаете файл, как бинарный блоками, на блоке вызываете decode/encode
Это у нормальных людей строки — это частный случай бинарных данных. В python3 — нет.
Давайте не переходить на уровень «настоящих шотландцев». Что вы подразумеваете, под тем, что в python3 строки не бинарные данные?
А в python возможно? Да неужели?
>>> 'Ху**ня'[4]
'н'
>>> 'Ху*ня'[4]
'я'
У вас в первом случае должна быть [3]? Ну выглядит как логичное и ожидаемое поведение, строка — последовательность символов, индексируясь по ней — получаем символы. Ещё раз есть языки, в которых на такой операции вы получите ошибку компиляции, это лучше?
Я вообще не знаю ни одного практически полезного алгоритма, для которого такая индексация годилась бы, а побайтовая индексация UTF-8 текста — не годилась бы.
1. encode вам в помощь.
2. ну и не работайте в таком случае не с python, зачем грызть кактус?) Есть C, который гораздо лучше подходит под обработку бинарных данных, python вообще не про это.
Но за эту блажь платится усложнением реализации, замедлением и усложнением языка. Впрочем это всё в духе Python, так что, в принципе, неудивительно.
Критикуешь — предлагай. Как вы посоветуете переписать реализацию? Можно хоть в виде PEP на оф. сайте. Всё сообщество будет вам благодарно.
Python3 по сравнению с Python2 — это как C++ по сравнению с C: выстрелить в ногу слегка сложнее, но всё равно не очень сложно, а разрушений — намного больше.
Всё смешалось, кони-люди. В C++ выстрелить в ногу сложнее или в C? Какие разрушения вы получите в случае с python? Я пытался, я менял служебные поля в рантайме, в большинстве случаев получал падение интерпретатора, никуда буферы не текли, стеки не переполнялись, произвольный код не выполнялся. Хотя достичь этого можно, но надо прям специально постараться, это не выстрел в ногу — это осознанный суицид.
Работать с данными как с последовательностью байт. А кодировку использовать там и тогда, когда это реально нужно.
Так используйте) Кто вам не разрешает?
Какой процент строк из вашей программы у вас отображается на экране? Зачем засорять работу с теми из них (а это, в типичном случае 90%, а во многих программах и 99%) сущностью, которая вам не нужна?
Касательно именно длинной арифметики, у меня данных нет, к сожалению.
По идее, операции написаны на C, используют в том числе и алгоритм Карацубы, правда, вряд ли создатели интерпретатора задавались целью применить столько же оптимизаций, сколько могут сделать создатели специализированных библиотек, в общем, если у кого есть бенчмарк, будем рады.
Я пока могу судить только по вычислению биномиальных коэфициентов и прочих чисел Фибоначчи — лично меня скорость устраивала. :)
Потому что вся работа со строками в Python3 построена вокруг двух предположений:
1. Строки (текст) и бинарные данные строго отделены друг от друга.
2. Во всех случаях когда мы работаем со строками мы всегда заранее знаем кодировку.
Поскольку в реальном мире оба этих предположения неверны, то строки в Python — это боль и содомия. Чего одна история с path-like объектами стоит!
Что для вас отстоят отдельно? Разные типы? Ну это логично, строки — частный случай бинарных данных, вполне можно навесить дополнительных проверок и операций, чтобы облегчить работу программисту. Как я уже упоминал, в некоторых языках даже индексирование не возможно.
Насчёт кодировок — константы всегда приходят из исходника с известной кодировкой, при чтении файлов, её тоже можно указать. Если он не известна то, что вы предлагаете делать?
Ждём от Вас статьи про std::string. Я не в курсе, слышал только про 2 реализации всех строковых алгоритмов в java: для ascii и для не ascii строк и флаг, указывающий на тип.
Ну и самое простое — это хранить массив из 4 байт на каждый символ. Вот только эффективно ли это?
В cpython удалось добиться не большого расхода памяти, при этом скрыть особенности реализации от пользователя, благодаря чему он может, например, обращаться по индексу, в отличие от Rust или Julia.
А так ли важно, сколько там наворотов, если абстрация не течёт? :)
Я, конечно, не в теме, поэтому могу ошибаться, но разве беспартийные, ВНЕЗАПНО, не подоставали членские билеты Единой России и не сформировали свою группу?
Главное, чтобы потом не надо было отобразить табличку, в которой более 100 элементов. А ведь иногда ещё и 1000 может прийти. Очень не каждый выдержит такое. Jira и confluence вот не всегда справляются.
Не только они. Вообще, наверно, большинство топиков с рейтингом больше 100 — это вот такие холивары, если не все топики.
Это всё конечно так, особенно в некоторых странах, но в других нет бесплатного обучения в колледже, и ты бы и рад отучиться на адвоката и получать несколько сотен тысяч в год, но приходится вкалывать в фастфуде за несколько десятков. Особенно, если у родителей нет денег оплатить тебе кредит на образование, зато есть счета из больницы, которая не менее платная, чем колледж.
Ну судя по статье таки не все офисы ещё перенесли.
на ютуб?)
Думается фейсбук скоро наймёт компанию из Мумбая для модерации вместо компании из Дублина.
>Ненавистники Python всегда говорят, что Python — это медленно. Но то, что некая программа, независимо от используемого языка программирования, может считаться быстрой или медленной, очень сильно зависит от разработчика, который её написал, от его знаний и от умения создавать оптимизированный и высокопроизводительный код.
он же:
>Дело тут, в основном, в том, что встроенные механизмы языка реализованы средствами C. Если описывать нечто средствами Python — нельзя добиться того же уровня производительности.
Ну если вам не надо, то никому не надо, это очевидно.
Там более весёлый механизм.
И вы не перепутали тело ф-ции и сигнатуру?
Некоторые ф-ции из стандартной библиотеки имеют такую сигнатуру, например bool.
Что выглядит вполне логичным, действительно, какие имя дать этому параметру? `o`, `x`, `a`?
И вполне логично запретить вызов
Что подтверждает только то, что это не было первостепенной задачей ни для кого. Иначе ввели бы раньше.
Ещё раз, python не про скорость и не работу с бинарными данными, он про читаемость, файл с несколькими кодировками — это не к читаемости. Создатели python не предусматривали такой сценарий, естественно, он в таком формате неоптимален, но люди, смешивающие кодировки, должны страдать.
В тоже время куча людей создаёт сайты на django, тесты и скрипты автоматизации на python и не жалуется.
Вы уверенны? Новички, приходящие в вашу команду, как это воспринимают? Интуитивно понятно?
Текст — это сложно. Я про это отписал, как починили по итогу?
Почему? Вы прочли бинарные данные — перегнали их в текст, обработали — перегнали обратно в бинарные. Можно даже сразу обрабатывать бинарные, `b'my_string'` вам в помощь. Если формат файла более-менее постоянен и позволяет описать их константами.
И вы так и не написали, как реализованы строки в C++.
Это проблемы python или ОС, которые сохраняют имена файлов в чём попало? Строка в python имеет определённую кодировку, вполне логично запретить туда записывать мусор. Для работы с файлами создали отдельный механизм, потому что это отдельная сущность. Зачем ломать из-за этого общий механизм?
Ну если вам ненужно, очевидно, что всем не нужно. Напишите в почтовую рассылку, просветите заблудшие души.
Про читаемость. Это если одним словом, если несколькими — это к дзену, там про бинарные данные ничего нет.
Опять же, могу только посоветовать написать в рассылку. Кстати, а как вы подсчитали урон? Можете поделиться?
Утверждение верное для любой технологии, даже молотка.
Это простой пример? Зачем вы храните разные кодировки в одном файле? В чём скрытый смысл? Как вы его обрабатываете сейчас? Чем? Зачем?
Читаете файл, как бинарный блоками, на блоке вызываете decode/encode
Давайте не переходить на уровень «настоящих шотландцев». Что вы подразумеваете, под тем, что в python3 строки не бинарные данные?
У вас в первом случае должна быть [3]? Ну выглядит как логичное и ожидаемое поведение, строка — последовательность символов, индексируясь по ней — получаем символы. Ещё раз есть языки, в которых на такой операции вы получите ошибку компиляции, это лучше?
1. encode вам в помощь.
2. ну и не работайте в таком случае не с python, зачем грызть кактус?) Есть C, который гораздо лучше подходит под обработку бинарных данных, python вообще не про это.
Критикуешь — предлагай. Как вы посоветуете переписать реализацию? Можно хоть в виде PEP на оф. сайте. Всё сообщество будет вам благодарно.
Всё смешалось, кони-люди. В C++ выстрелить в ногу сложнее или в C? Какие разрушения вы получите в случае с python? Я пытался, я менял служебные поля в рантайме, в большинстве случаев получал падение интерпретатора, никуда буферы не текли, стеки не переполнялись, произвольный код не выполнялся. Хотя достичь этого можно, но надо прям специально постараться, это не выстрел в ногу — это осознанный суицид.
Так используйте) Кто вам не разрешает?
Вот здесь вообще не понял.
Вот здесь есть несколько примеров.
По идее, операции написаны на C, используют в том числе и алгоритм Карацубы, правда, вряд ли создатели интерпретатора задавались целью применить столько же оптимизаций, сколько могут сделать создатели специализированных библиотек, в общем, если у кого есть бенчмарк, будем рады.
Я пока могу судить только по вычислению биномиальных коэфициентов и прочих чисел Фибоначчи — лично меня скорость устраивала. :)
Что для вас отстоят отдельно? Разные типы? Ну это логично, строки — частный случай бинарных данных, вполне можно навесить дополнительных проверок и операций, чтобы облегчить работу программисту. Как я уже упоминал, в некоторых языках даже индексирование не возможно.
Насчёт кодировок — константы всегда приходят из исходника с известной кодировкой, при чтении файлов, её тоже можно указать. Если он не известна то, что вы предлагаете делать?
Ну и самое простое — это хранить массив из 4 байт на каждый символ. Вот только эффективно ли это?
В cpython удалось добиться не большого расхода памяти, при этом скрыть особенности реализации от пользователя, благодаря чему он может, например, обращаться по индексу, в отличие от Rust или Julia.
А так ли важно, сколько там наворотов, если абстрация не течёт? :)
Опять же, многие не переставали быть членами Единой России, вроде бы, просто не афишировали это.