я не соглашусь, что она распространённая. Конкретно HashMap, Array — типы данных из Жавы. Честно, за 11 лет работы ни разу не слышал слова "хэшмап" в контексте питона. Map, Mapping может быть ещё более-менее, хотя в первом случае путается с функцией map(), а во втором — с collections.abc.Mapping. Конечно, я пойму, о чём идёт речь, если кто вдруг выскажется, но всё-таки предпочитаю называть лопату лопатой (call a spade a spade) :)
С другой стороны YMMV — я не работал везде, и сказать что никто не использует слова "хэшмап" вместо дикта/словаря и "массив" (прям-таки Pascal :)) вместо листа/списка, тоже не могу.
В чужой монастырь, как говорится.
вот и я о том же, просто терминология для меня показатель. На чём пишешь, так и говоришь ...
А "хэшмап" — это перевод какого слова?
HashMap как тип в Жаве соответствует dict как типу в питоне. Т.е. перевод HashMap на язык питона — dict. :) В примере с языками я всего лишь хотел подчеркнуть, что если речь идёт о питоне, то пользоваться стоит питоновскими терминами.
От того что где-то его называют "словарём" (как в моем основном сишарпе, к примеру) ничего не меняет
Окей, обратный пример. Я прихожу на собеседование Java Senior Dev и говорю, если ключик в словаре ("in") is None..., или напишем лямбда функцию возвращающую списочек ...
Есть ли вероятность, что я бы прошёл собеседование дальше этих фраз? Даже если я бы мог написать код на жаве правильно, это всё равно выдаёт человека, которому Жава не настолько близка, чтобы он выражался принятой в ней терминологией. Ибо поработав с языком -дцать лет, ты уже не думаешь, что в теории дикт и хэшмап это одно и то же, а говоришь то, что видишь чаще всего. С другой стороны, мне вряд ли вообще пришло бы в голову назвать java.util.HashMap диктом — просто потому, что он называется HashMap, а дикт, это вроде вполне конкретный тип в питоне...
Хотя возможно я и переоцениваю влияние языка (ЯП) на язык (которым выражаешься) и обратно.
У питона правда несколько другой подход к реализации данной функции:
Caution This does not support parsing arbitrary ISO 8601 strings — it is only intended as the inverse operation of datetime.isoformat(). A more full-featured ISO 8601 parser, dateutil.parser.isoparse is available in the third-party package dateutil.
Я никакой x in dict.keys() нигде даже близко не писал
а что, примеры уже нельзя приводить? :) я просто хочу показать, что идиомы из одних мест они не всегда уместны в других.
Логика уровня /b/.
скажите, что не так в этой логике. Иначе, это выглядит как логика уровня 0. Я хотя бы аргументировал, вы же просто ляпнули.
Вы же не говорите по-английски, используя дословный перевод с русского.
Конечно говорю. Трейт, тайпкласс, имплементировать, инвестигейт, багтрекер
пардон вы ошиблись — во-первых, здесь нет перевода. Трейт — это англоязычный термин, который не переведён, а взят как есть, перевод был бы "особенность", "черта". Во-вторых, это общепринятая практика, например слово "танк" это тоже заимствование из английского, без перевода (перевод — "бочка"). Впрочем, кому я объясняю, вы это и сам прекрасно знаете. И либо вы понимаете ошибку в вашей логике и намеренно её делаете, либо не понимаете, тогда увы о чём разговор про логику уровня /b/.
Ну значит вы "питон разработчик".
Да, когда работаешь на питоне, наиболее эффективно работать используя подходы, принятые в питоне. Пиша на Жаве — подходы, принятые в Жаве. Если вы считаете, что на всех языках одинаковые идиомы одинаково эффективны, вы не "просто разработчик", а просто не разработчик. (Не имея в виду лично вас.)
Я не хочу вас оскорблять, я вас не знаю, вы меня не знаете. Кто и что в вашей системе координат на каком уровне, меня также не оскорбляет. Я просто указываю вам на те вещи, в которых, на мой взгляд, вы ошибаетесь. А уж как вам к этому относиться, я на это никак повлиять не могу.
Суть задачи — как лучше хранить привязку номер телефона — имя пользователя. Или Map<Int, String> или просто String[]
тогда не очень понятно, в чём заключается доп.условие что номера только 8-800 и 8-499. Если мы храним номер как 10-значный int, то это одно. Если мы храним его как 7-значный инт плюс префикс 800/499 (может быть и бред, но мало ли кому что в голову взбредёт) то одним интом не отделаешься.
если вы не знаете что такое хэшмап
я знаю, что такое хэшмап. Но если вы называете тип данных dict хэшмапом, то я очень сомневаюсь, что вы знаете, где вы находитесь. Если вы используете in для проверки наличия ключа в питоновском дикте так:
if "x" in the_dict.keys()
то да, так можно делать. Но если вы мне предлагаете должность сеньора и при этом утверждаете, что так правильно делать, то извините.
Map<Int, String> или просто String[]
вот о чём я и говорил, к питону это не имеет никакого отношения.
"Какие-то дельфи" — да нет, ваще-то почти во всех языках принято так называть.
если вы считаете, что жавовская термонология уместна во всех языках, я не думаю, что мне с вами по пути, потому что в таком случае с вероятностью 100% вы будете использовать и другие жавовские приёмы. Если вы пишете на жаве, пишите на жаве. Не надо писать жавовскими идиомами ни на питоне ни на дельфях. Вы же не говорите по-английски, используя дословный перевод с русского.
Так вот, в питоне нет типа данных "хэшмап". И если вы имеете в виду дикт, то я развернусь и уйду. Если же это какой-то самописный class HashMap, то возможно ещё подумаю, хотя необходимость такого в питоне сомнительна.
Кругозор "знаю больше 1 языка" тоже приветствуется и является бонусом.
Я знаю довольно много языков, как ЯП, так и человеческих. И именно поэтому, для меня важна точность терминологии. Называть хэшмапом дикт в питоне, это то же самое, что называть машину в английском "machine". Да, формально "car" и "auto" это тоже machine, но люди так не говорят. Просто сразу видно, что вы не местный. Ничего личного, но если вы при этом работаете в фирме переводов, то досвидос. Так же и со словарями и списками в питоне. Ничего личного, я уважаю Жаву как язык. Но работаю на питоне.
А если эти решения принимаются уже над подсознательном уровне? Например, много лет назад были все эти знания, ...
Я не очень понял предпосылку. Таки знания были? Таки можно аргументировать или нет?
Скажем, из последних примеров, пришёл программист на РНР в питон и пишет:
if "x" in the_dict.keys(): ...
Да, он пишет на подсознательном уровне потому, что isset() в питоне нет. Если я ему в ревью напишу, что в питоне есть оператор "x" in the_dict, это кому-то повредит? Ущемит эго похаписта? Может он как-то аргументировать в свою пользу или нет?
Или вариант 2: в Python 3.7 добавили функцию datetime.fromisoformat(). Да, раньше приходилось либо писать в каждом проекте это заново, т.е. просто копипастить ("на подсознательном уровне"), либо использовать какую-то библиотеку. Если я в ревью напишу автору кода, что "в 3.7 это уже встроено", это кому-то как-то повредит? Ущемит эго?
Я же не буду, в обоих случаях, орать и материться "вы тупые свиньи, тупой похапист и идиот, который за 3 года не удосужился в релиз ноты глянуть". Больше того, то, что я могу дать им новые знания, мне гораздо важнее того, что код в данном конкретном месте будет лучше (мне было бы быстрее и проще самому взять и поправить). Это как дать рыбу чтобы утолить голод, или научить рыбачить.
Но знания устаревают, и если ты считаешь себя пригодным для работы в современных условиях, твои знания должны быть современны. А если ты считаешь обновления знаний "бессмысленной потерей времени", ну будешь через 10 лет как те, кто сейчас на дельфи ваяют монохромные ГУИ под виндовс 98 для кассовых компов в Нигерии. Хотя возможно, это и было нормой 20 лет назад.
Поэтому да, если вы не можете аргументировать ваши решения, которые вы принимаете здесь и сейчас, то это буллшит.
хранится список номеров телефонов или номер телефона это ключ к записи? в чём вообще суть задачи?
"хэшмап или массив" если бы мне на собесе про питон упомянули что-то такое, я бы сказал "пардон, я кажется ошибся адресом", развернулся и ушёл. Как бы есть словарь и список (ну может быть дикт и лист), но хешмап и массив, это какие-то дельфи или я не знаю. Если человек не использует привычную терминологию, что-то значит не то в конторе.
шанс знания любого из них составляет 95%, то шанс безошибочного ответа по всему чек-листу составляет 23%
во-первых, нет такой величины как "шанс знания", если ты работаешь с этим инструментом, то объём знаний зависит не от шанса, а от опыта работы. Да, ты можешь не использовать какую-то часть языка, но как раз именно объём (и глубина) знаний и отличает например сеньора от джуна. Если бы у сеньора был такой же "шанс знаний", как и у джуна, наверно, никому не требовались бы сеньоры.
Во-вторых, знать — это не обязательно в 100%-ном объёме помнить все детали. Знать — значит понимать и быть способным аргументировать (подразумевается, верно). Если человек может и не "знать", почему (к примеру) поиск в линейном массиве менее эффективен, чем в хэшированном дереве, то один может это вывести на ходу, а для другого разницы никакой нет — и это тоже один из факторов, которые проверяются на собеседовании.
Не нужно знать ответы на 100% вопросов, но уровень знания и понимания технологии коррелирует с уровнем ответов. Поэтому и спрашивают.
2.
Теоретические знания помогут на практике только чтобы осадить ретивых коллег
Это либо наивность, либо провокация. Если бы было так, наверно сеньорам платили бы 23% от джунов (типа сеньор больше знает и поэтому будет злоупотреблять знаниями?)
Знания, конечно, можно и найти. Но представьте себе, если ваш сотрудник вместо "писания кода руками" только и делает что ищет эти "знания" в интернете? Знание, в том числе теоретическое, абсолютно необходимо для писания кода руками. Потому что каждый раз, при написании кода, вы принимаете решение. Если у вас нет знания за этим, то ваше решение — буллшит. И совершенно оправдано будет "осадить ретивого коллегу в комментах", если он не понимает, что — и почему — он наваял.
А умение отыскивать и применять, если за этим не стоит фундаментального знания и понимания технологии, приводит к такому: https://habr.com/ru/post/521104/
при отрицании используется только родительный падеж. Нет чего, а не "нет что". В просторечии можно конечно и заменять, но например если в просторечное "Не вижу чемодан" добавить какой чемодан — "Не вижу зелёный чемодан" звучит неуклюже, в отличие от "Не вижу зелёного чемодана".
"Что не хватает ИИ" имеет исключительный смысл "какой-то предмет (=что) не хватает (=руками) кого (=ИИ)".
зато для веба там только джанго и в целом не очень есть альтернативы
далеко не так. Для веба там полно всего. Начиная от Flask и aiohttp до кучи библиотек и фреймворков, которые имеют невысокую популярность потому, что первые 3 покрывают 80% сценариев.
Если вопрос про ЦМС, то да, с ними сложнее… но использовать ЦМС для чего-то чуть более сложного, чем демо сайт ЦМС, обычно плохая идея. В части разработки нестандартных решений питон несравним. А там, где нужно стоковый сайт с 2 страницами и блогом, питон конечно не нужен — вордпресс проще.
из-за популярности языка на нём крайне неумело пишут
кажется, это некорректная причинно-следственная связь :) Популярность потому, что просто писать. Просто писать в том числе и потому, что нет всяких сущностей вроде типизации, public-private, static и т.д.
Я не думаю, что будь питон статически типизированным, миру было бы от этого легче. Ну писали бы ещё более невменяемый код на Джаве/С.
Подтекст в том, что не типизированность языка определяет стиль кода и умелость исполнителя.
В Питоне нет проблем с типизацией. Проблема у тех, кто не осилил. Если на английском выражаться, используя дословный перевод с русского, вряд ли это хорошая идея. Так же и подход к типам, используемый в джавах и сях, в Питоне неуместен. Ну и наоборот, очевидно.
В современных ИДЕ и с type hinting ошибки типов в Питоне почти исключены. При этом, type hinting не для валидации типов, а для удобства программиста. Конечно если он игнорирует предупреждения от ИДЕ, то букву Д надо добавить — через тире после имени исполнителя. Но как типизация поможет в случаях, если исполнитель — Д, я думаю — никак.
Не знаю как в РНР, в других ЯП библиотеки позволяют передать в одном вызове несколько запросов.
Парсинг SQL занимает наносекунды, составление плана в случае использования prepared statement также скорее всего берётся из кеша (а если и нет, то затраты на план — величина меньшего порядка, чем собственно выполнение).
В итоге — да, пару десятков мс сэкономить можно, при отсутствии передачи результатов. Стоит ли это усилий? Оптимизация собственно запросов может дать прирост скорости совсем других порядков. Ну а если всё остальное уже супер оптимизировано и всё равно медленно — миллисекунды не спасут, пожалуй, стоит задуматься о horizontal scalability.
Спасибо за ответ, похоже невнимательно прочитал. В целом так и догадывался.
Наверно так удобнее в случае API с непрерывными страницами, если же требуется показывать кол-во страниц, а-ля джанго админ, то пожалуй удобнее "строго больше". Хотя не сильно сложно и убрать один лишний элемент)
Вопрос насчёт курсорной пагинации. Есть ли какое-то теоретическое обоснование тому, что берётся страница на 1 элемент больше и делается запрос id >= ? где? — "лишний" элемент. Ведь можно и с обычным размером страницы делать запрос вида id > ? где? — последний элемент обычной страницы, это кажется гораздо удобнее, так как не надо производить дополнительные манипуляции с лимитом и отрезанием этого лишнего элемента.
Как мне кажется, не освещён один важный момент.
Главный аргумент вегетарианства — то, что мясоеды (точнее, понятное дело, те, кто разводит и забивает животных) причиняют животным боль.
Но 1) можно разводить животных, не причиняя им боль 2) можно (и давно уже так происходит) забивать животных, не причиняя им боль 3) а если не разводить этих животных, которые веками жили только ради человека — будут ли вообще эти животные на планете? Как вы себе представляете диких домашних коров, свиней, баранов? Только благодаря употреблению продуктов от/из них, они существуют в таком количестве. Поэтому про "негуманное" отношение к ним немного смешно слышать.
И наконец, вегетарианство входит в жёсткие противоречия с другими традициями вроде курбан-байрама, что поднимает один из самых сложных вопросов: традиция/политкорректность vs разумность и рациональность.
да, подумав, пожалуй не в тему =)
я не соглашусь, что она распространённая. Конкретно HashMap, Array — типы данных из Жавы. Честно, за 11 лет работы ни разу не слышал слова "хэшмап" в контексте питона.
Map,Mappingможет быть ещё более-менее, хотя в первом случае путается с функцией map(), а во втором — сcollections.abc.Mapping. Конечно, я пойму, о чём идёт речь, если кто вдруг выскажется, но всё-таки предпочитаю называть лопату лопатой (call a spade a spade) :)С другой стороны YMMV — я не работал везде, и сказать что никто не использует слова "хэшмап" вместо дикта/словаря и "массив" (прям-таки Pascal :)) вместо листа/списка, тоже не могу.
вот и я о том же, просто терминология для меня показатель. На чём пишешь, так и говоришь ...
HashMap как тип в Жаве соответствует dict как типу в питоне. Т.е. перевод HashMap на язык питона — dict. :) В примере с языками я всего лишь хотел подчеркнуть, что если речь идёт о питоне, то пользоваться стоит питоновскими терминами.
Окей, обратный пример. Я прихожу на собеседование Java Senior Dev и говорю, если ключик в словаре ("in") is None..., или напишем лямбда функцию возвращающую списочек ...
Есть ли вероятность, что я бы прошёл собеседование дальше этих фраз? Даже если я бы мог написать код на жаве правильно, это всё равно выдаёт человека, которому Жава не настолько близка, чтобы он выражался принятой в ней терминологией. Ибо поработав с языком -дцать лет, ты уже не думаешь, что в теории дикт и хэшмап это одно и то же, а говоришь то, что видишь чаще всего. С другой стороны, мне вряд ли вообще пришло бы в голову назвать java.util.HashMap диктом — просто потому, что он называется HashMap, а дикт, это вроде вполне конкретный тип в питоне...
Хотя возможно я и переоцениваю влияние языка (ЯП) на язык (которым выражаешься) и обратно.
Спасибо :) как раз к вопросу о пользе знаний.
У питона правда несколько другой подход к реализации данной функции:
https://docs.python.org/3/library/datetime.html#datetime.datetime.fromisoformat
что, конечно, немного удивительно.
а что, примеры уже нельзя приводить? :) я просто хочу показать, что идиомы из одних мест они не всегда уместны в других.
скажите, что не так в этой логике. Иначе, это выглядит как логика уровня 0. Я хотя бы аргументировал, вы же просто ляпнули.
пардон вы ошиблись — во-первых, здесь нет перевода. Трейт — это англоязычный термин, который не переведён, а взят как есть, перевод был бы "особенность", "черта". Во-вторых, это общепринятая практика, например слово "танк" это тоже заимствование из английского, без перевода (перевод — "бочка"). Впрочем, кому я объясняю, вы это и сам прекрасно знаете. И либо вы понимаете ошибку в вашей логике и намеренно её делаете, либо не понимаете, тогда увы о чём разговор про логику уровня /b/.
Да, когда работаешь на питоне, наиболее эффективно работать используя подходы, принятые в питоне. Пиша на Жаве — подходы, принятые в Жаве. Если вы считаете, что на всех языках одинаковые идиомы одинаково эффективны, вы не "просто разработчик", а просто не разработчик. (Не имея в виду лично вас.)
Я не хочу вас оскорблять, я вас не знаю, вы меня не знаете. Кто и что в вашей системе координат на каком уровне, меня также не оскорбляет. Я просто указываю вам на те вещи, в которых, на мой взгляд, вы ошибаетесь. А уж как вам к этому относиться, я на это никак повлиять не могу.
ну я собственно говорил
так что видимо это не тот случай. :)
вместо Z —
+00:00хотя согласен, Z это практически стандарт. Сам немного напрягался по этому поводу.
тогда не очень понятно, в чём заключается доп.условие что номера только 8-800 и 8-499. Если мы храним номер как 10-значный int, то это одно. Если мы храним его как 7-значный инт плюс префикс 800/499 (может быть и бред, но мало ли кому что в голову взбредёт) то одним интом не отделаешься.
я знаю, что такое хэшмап. Но если вы называете тип данных
dictхэшмапом, то я очень сомневаюсь, что вы знаете, где вы находитесь. Если вы используете in для проверки наличия ключа в питоновском дикте так:то да, так можно делать. Но если вы мне предлагаете должность сеньора и при этом утверждаете, что так правильно делать, то извините.
вот о чём я и говорил, к питону это не имеет никакого отношения.
если вы считаете, что жавовская термонология уместна во всех языках, я не думаю, что мне с вами по пути, потому что в таком случае с вероятностью 100% вы будете использовать и другие жавовские приёмы. Если вы пишете на жаве, пишите на жаве. Не надо писать жавовскими идиомами ни на питоне ни на дельфях. Вы же не говорите по-английски, используя дословный перевод с русского.
Так вот, в питоне нет типа данных "хэшмап". И если вы имеете в виду дикт, то я развернусь и уйду. Если же это какой-то самописный
class HashMap, то возможно ещё подумаю, хотя необходимость такого в питоне сомнительна.Я знаю довольно много языков, как ЯП, так и человеческих. И именно поэтому, для меня важна точность терминологии. Называть хэшмапом дикт в питоне, это то же самое, что называть машину в английском "machine". Да, формально "car" и "auto" это тоже machine, но люди так не говорят. Просто сразу видно, что вы не местный. Ничего личного, но если вы при этом работаете в фирме переводов, то досвидос. Так же и со словарями и списками в питоне. Ничего личного, я уважаю Жаву как язык. Но работаю на питоне.
Я не очень понял предпосылку. Таки знания были? Таки можно аргументировать или нет?
Скажем, из последних примеров, пришёл программист на РНР в питон и пишет:
Да, он пишет на подсознательном уровне потому, что
isset()в питоне нет. Если я ему в ревью напишу, что в питоне есть оператор"x" in the_dict, это кому-то повредит? Ущемит эго похаписта? Может он как-то аргументировать в свою пользу или нет?Или вариант 2: в Python 3.7 добавили функцию
datetime.fromisoformat(). Да, раньше приходилось либо писать в каждом проекте это заново, т.е. просто копипастить ("на подсознательном уровне"), либо использовать какую-то библиотеку. Если я в ревью напишу автору кода, что "в 3.7 это уже встроено", это кому-то как-то повредит? Ущемит эго?Я же не буду, в обоих случаях, орать и материться "вы тупые свиньи, тупой похапист и идиот, который за 3 года не удосужился в релиз ноты глянуть". Больше того, то, что я могу дать им новые знания, мне гораздо важнее того, что код в данном конкретном месте будет лучше (мне было бы быстрее и проще самому взять и поправить). Это как дать рыбу чтобы утолить голод, или научить рыбачить.
Но знания устаревают, и если ты считаешь себя пригодным для работы в современных условиях, твои знания должны быть современны. А если ты считаешь обновления знаний "бессмысленной потерей времени", ну будешь через 10 лет как те, кто сейчас на дельфи ваяют монохромные ГУИ под виндовс 98 для кассовых компов в Нигерии. Хотя возможно, это и было нормой 20 лет назад.
Поэтому да, если вы не можете аргументировать ваши решения, которые вы принимаете здесь и сейчас, то это буллшит.
чисто любопытства ради.
1.
во-первых, нет такой величины как "шанс знания", если ты работаешь с этим инструментом, то объём знаний зависит не от шанса, а от опыта работы. Да, ты можешь не использовать какую-то часть языка, но как раз именно объём (и глубина) знаний и отличает например сеньора от джуна. Если бы у сеньора был такой же "шанс знаний", как и у джуна, наверно, никому не требовались бы сеньоры.
Во-вторых, знать — это не обязательно в 100%-ном объёме помнить все детали. Знать — значит понимать и быть способным аргументировать (подразумевается, верно). Если человек может и не "знать", почему (к примеру) поиск в линейном массиве менее эффективен, чем в хэшированном дереве, то один может это вывести на ходу, а для другого разницы никакой нет — и это тоже один из факторов, которые проверяются на собеседовании.
Не нужно знать ответы на 100% вопросов, но уровень знания и понимания технологии коррелирует с уровнем ответов. Поэтому и спрашивают.
2.
Это либо наивность, либо провокация. Если бы было так, наверно сеньорам платили бы 23% от джунов (типа сеньор больше знает и поэтому будет злоупотреблять знаниями?)
Знания, конечно, можно и найти. Но представьте себе, если ваш сотрудник вместо "писания кода руками" только и делает что ищет эти "знания" в интернете? Знание, в том числе теоретическое, абсолютно необходимо для писания кода руками. Потому что каждый раз, при написании кода, вы принимаете решение. Если у вас нет знания за этим, то ваше решение — буллшит. И совершенно оправдано будет "осадить ретивого коллегу в комментах", если он не понимает, что — и почему — он наваял.
А умение отыскивать и применять, если за этим не стоит фундаментального знания и понимания технологии, приводит к такому:
https://habr.com/ru/post/521104/
при отрицании используется только родительный падеж. Нет чего, а не "нет что". В просторечии можно конечно и заменять, но например если в просторечное "Не вижу чемодан" добавить какой чемодан — "Не вижу зелёный чемодан" звучит неуклюже, в отличие от "Не вижу зелёного чемодана".
"Что не хватает ИИ" имеет исключительный смысл "какой-то предмет (=что) не хватает (=руками) кого (=ИИ)".
далеко не так. Для веба там полно всего. Начиная от Flask и aiohttp до кучи библиотек и фреймворков, которые имеют невысокую популярность потому, что первые 3 покрывают 80% сценариев.
https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=fortune&l=zijzen-1
Если вопрос про ЦМС, то да, с ними сложнее… но использовать ЦМС для чего-то чуть более сложного, чем демо сайт ЦМС, обычно плохая идея. В части разработки нестандартных решений питон несравним. А там, где нужно стоковый сайт с 2 страницами и блогом, питон конечно не нужен — вордпресс проще.
кажется, это некорректная причинно-следственная связь :) Популярность потому, что просто писать. Просто писать в том числе и потому, что нет всяких сущностей вроде типизации, public-private, static и т.д.
Я не думаю, что будь питон статически типизированным, миру было бы от этого легче. Ну писали бы ещё более невменяемый код на Джаве/С.
Подтекст в том, что не типизированность языка определяет стиль кода и умелость исполнителя.
В Питоне нет проблем с типизацией. Проблема у тех, кто не осилил. Если на английском выражаться, используя дословный перевод с русского, вряд ли это хорошая идея. Так же и подход к типам, используемый в джавах и сях, в Питоне неуместен. Ну и наоборот, очевидно.
В современных ИДЕ и с type hinting ошибки типов в Питоне почти исключены. При этом, type hinting не для валидации типов, а для удобства программиста. Конечно если он игнорирует предупреждения от ИДЕ, то букву Д надо добавить — через тире после имени исполнителя. Но как типизация поможет в случаях, если исполнитель — Д, я думаю — никак.
Не знаю как в РНР, в других ЯП библиотеки позволяют передать в одном вызове несколько запросов.
Парсинг SQL занимает наносекунды, составление плана в случае использования prepared statement также скорее всего берётся из кеша (а если и нет, то затраты на план — величина меньшего порядка, чем собственно выполнение).
В итоге — да, пару десятков мс сэкономить можно, при отсутствии передачи результатов. Стоит ли это усилий? Оптимизация собственно запросов может дать прирост скорости совсем других порядков. Ну а если всё остальное уже супер оптимизировано и всё равно медленно — миллисекунды не спасут, пожалуй, стоит задуматься о horizontal scalability.
Спасибо за ответ, похоже невнимательно прочитал. В целом так и догадывался.
Наверно так удобнее в случае API с непрерывными страницами, если же требуется показывать кол-во страниц, а-ля джанго админ, то пожалуй удобнее "строго больше". Хотя не сильно сложно и убрать один лишний элемент)
Вопрос насчёт курсорной пагинации. Есть ли какое-то теоретическое обоснование тому, что берётся страница на 1 элемент больше и делается запрос
id >= ?где? — "лишний" элемент. Ведь можно и с обычным размером страницы делать запрос видаid > ?где? — последний элемент обычной страницы, это кажется гораздо удобнее, так как не надо производить дополнительные манипуляции с лимитом и отрезанием этого лишнего элемента.Именно такой пример приведён например в Shopify:
https://engineering.shopify.com/blogs/engineering/pagination-relative-cursors
Я тоже использую именно "строго больше", может быть я что-то упускаю?
Безопасность.
Часто ли вы слышите, что "у поезда отказали тормоза"? В отличие от фур и автомобилей.
чем обусловлена эта невозможность?
Снижение давления = увеличение тормозной силы. Вопрос только в регуляторе давления.
Как мне кажется, не освещён один важный момент.
Главный аргумент вегетарианства — то, что мясоеды (точнее, понятное дело, те, кто разводит и забивает животных) причиняют животным боль.
Но 1) можно разводить животных, не причиняя им боль 2) можно (и давно уже так происходит) забивать животных, не причиняя им боль 3) а если не разводить этих животных, которые веками жили только ради человека — будут ли вообще эти животные на планете? Как вы себе представляете диких домашних коров, свиней, баранов? Только благодаря употреблению продуктов от/из них, они существуют в таком количестве. Поэтому про "негуманное" отношение к ним немного смешно слышать.
И наконец, вегетарианство входит в жёсткие противоречия с другими традициями вроде курбан-байрама, что поднимает один из самых сложных вопросов: традиция/политкорректность vs разумность и рациональность.
Это самое интересное.
Возьмём СПБ: 22 июня закат в 22:26, при этом светло ещё до пол-первого.
22 декабря закат в 15:55.
Сегодня — в 21:12.
Попробуй тут ложиться через час после заката.