> уничтожить поток.… Поэтому Питон и не имеет такой возможности.
Я считаю, что реализовать функцию (в ядре питона) уничтожения потока не тяжело, её специально не делают — как бы подталкивают к правильной разработке программ. Т.е. это скорее является «фичей» чем «минусом».
Про поддержку отчасти согласен, но опять же «меньше платишь — меньше получаешь», например я бы не стал ждать от 200$ андройд-фона особой поддержки, а galaxy s имел поддержку до 2 лет и получил бы android 4.0 если бы аппаратные ограничения.
Хотя можно через 2 года купить второй андройд не превысив цены айфона, что суммарное время поддержки будет не меньше.
Либо купить айфон и сразу иметь долгую поддержку.
Может это рассматривать как ассортимент? разные цены — разная поддержка.
> С лямбдой проблема может быть в том, что сначала мы создадим лист, и только потом просуммируем все его элементы. Если файл огромный — мы зря потратим память на создание этого листа.
Если файл огромный мы зря потратим память на «open().readlines()» (для обоих случаев), лучше использовать просто «open()»
try… except можно пренебречь если «не цифры» пропустить «string.isdigit()»
в итоге «однострочник» мог-бы выглядеть например так:
sumOfFile = lambda filename:sum( imap(lambda x:int(x), ifilter(lambda x:x.isdigit(), imap(lambda x:x.strip(), open(filename,'rb')))) )
> Помещайте CSS файлы в начале страницы
>… служит отличным индикатором загрузки страницы для пользователя и улучшает общее впечатление от сайта.
В одной из подобных статей (по моему тут же на хабре) рекомендовали наоборот css файлы помещать в конец страницы, с причиной, что при этом стили накладываются на документ разом, а если вставлять в начало, то будет происходить (многоразовая) перерисовка стилей, по мере подгрузки/построения документа при этом тратиться больше ресурсов/времени.
Можно узнать какие-нибудь технические подробности? Где хостится? Надежность (защита от потерь)?
Какие есть лимиты? Например что будет если непрерывно заливать «random» данные или скачивающиеся «торенты»?
Что будет если залил 10Тб и не проплатил следующие месяцы (речь про «релиз» с платными аккаунтами)?
> ведущих деятельность на территории ЕС, включая Twitter,
Я думал что twitter ведет деятельность на территории US, а весь мир ходит к ним (как бы в гости), в этом случае получается что пользователи и сам twitter находятся на территории US, а значит и закон там US, и данный закон не «может их штрафовать».
Конечно они могут у себя «забанить» сайт, но это, вроде, нарушение о свободе…
> db.users.find( { numbers: { $in: [ 390, 754, 454 ] } } );
> т.е. билет должен обязательно содержать эти три номера.
$in — numbers должен быть равен любому элементу из входного массива (т.е. присутствует в массиве)
$all — все элементы входного массива должны присутствовать в numbers
> Инлайн колбэки дорогие
> Надеюсь, что прогнав пару тестов с колбеками и без вы поймете то, о чем я говорю
Прогнал тесты: pastebin.com/6SRADFpr
На моем буке вызов inline callback занимает 0,000007 сек — так что смешно говорить что они дорогие.
Про селект в mongo: в проекте который сейчас разрабатываю база около 2Гб, выборка 20 элементов занимает 4..6мс, если уж экономить то мили-секундами, а не микро-секундами.
Сделал 1000 (в 100 потоков) запросов к проекту: через asyncmongo 9.5 сек, через pymongo 11.5 сек, разница в 2сек.
Я согласен что в данном случае время затрачиваемое на запрос к монго «не существенно», но все же.
У вас есть цифры того что pymongo лучше чем asyncmongo?
> Все замечательно кроме бесполезности этого решения для большинства случаев. Оверхед от инлайн колбэка с yeld-ами на порядок, если не полтора увеличивает время отработки.
Зато улучшается читаемость кода и скорость разработки, ибо сейчас все сидели бы в asm или c++.
> Нужно очень постараться, чтобы селект в монго занял столько времени, что потребует асинхронной обертки, например какие-то сложные массовые операции, большие инсерты и т.д.
Вы сами ответили на свое предложение, да и глупо использовать синхронные методы в асинхронном фреймворке.
Я рассматриваю "$50К за 50%" так: после покупки 50% «продукта» инвестором последуют различные затраты на развитие (зп разработчика), поэтому владельцы продукта должны поровну вкладывать в развитие, а насколько мне известно инвестор предложил только 50К на все, значит можно рассматривать это так: 25К за 50% и 25К на расходы, при этом второй «партнер» должен поступить точно так же: 25К на расходы (вторые 25К он не тратит т.к. 50% ему и так принадлежат), отсюда видно что инвестор получает 50% за 25К.
А вообще я с автором согласен, лучше что-то чем ничего.
Почему?
Я считаю, что реализовать функцию (в ядре питона) уничтожения потока не тяжело, её специально не делают — как бы подталкивают к правильной разработке программ. Т.е. это скорее является «фичей» чем «минусом».
Хотя можно через 2 года купить второй андройд не превысив цены айфона, что суммарное время поддержки будет не меньше.
Либо купить айфон и сразу иметь долгую поддержку.
Может это рассматривать как ассортимент? разные цены — разная поддержка.
Если файл огромный мы зря потратим память на «open().readlines()» (для обоих случаев), лучше использовать просто «open()»
try… except можно пренебречь если «не цифры» пропустить «string.isdigit()»
в итоге «однострочник» мог-бы выглядеть например так:
sumOfFile = lambda filename:sum( imap(lambda x:int(x), ifilter(lambda x:x.isdigit(), imap(lambda x:x.strip(), open(filename,'rb')))) )
>… служит отличным индикатором загрузки страницы для пользователя и улучшает общее впечатление от сайта.
В одной из подобных статей (по моему тут же на хабре) рекомендовали наоборот css файлы помещать в конец страницы, с причиной, что при этом стили накладываются на документ разом, а если вставлять в начало, то будет происходить (многоразовая) перерисовка стилей, по мере подгрузки/построения документа при этом тратиться больше ресурсов/времени.
Какие есть лимиты? Например что будет если непрерывно заливать «random» данные или скачивающиеся «торенты»?
Что будет если залил 10Тб и не проплатил следующие месяцы (речь про «релиз» с платными аккаунтами)?
Я думал что twitter ведет деятельность на территории US, а весь мир ходит к ним (как бы в гости), в этом случае получается что пользователи и сам twitter находятся на территории US, а значит и закон там US, и данный закон не «может их штрафовать».
Конечно они могут у себя «забанить» сайт, но это, вроде, нарушение о свободе…
Было бы не плохо если mail.ru сделали подобное, да и не только mail.ru.
> т.е. билет должен обязательно содержать эти три номера.
$in — numbers должен быть равен любому элементу из входного массива (т.е. присутствует в массиве)
$all — все элементы входного массива должны присутствовать в numbers
А на счет беспредела согласен.
Alt + ' — переключение между окнами одного приложения
> Надеюсь, что прогнав пару тестов с колбеками и без вы поймете то, о чем я говорю
Прогнал тесты: pastebin.com/6SRADFpr
На моем буке вызов inline callback занимает 0,000007 сек — так что смешно говорить что они дорогие.
Про селект в mongo: в проекте который сейчас разрабатываю база около 2Гб, выборка 20 элементов занимает 4..6мс, если уж экономить то мили-секундами, а не микро-секундами.
Сделал 1000 (в 100 потоков) запросов к проекту: через asyncmongo 9.5 сек, через pymongo 11.5 сек, разница в 2сек.
Я согласен что в данном случае время затрачиваемое на запрос к монго «не существенно», но все же.
У вас есть цифры того что pymongo лучше чем asyncmongo?
Зато улучшается читаемость кода и скорость разработки, ибо сейчас все сидели бы в asm или c++.
> Нужно очень постараться, чтобы селект в монго занял столько времени, что потребует асинхронной обертки, например какие-то сложные массовые операции, большие инсерты и т.д.
Вы сами ответили на свое предложение, да и глупо использовать синхронные методы в асинхронном фреймворке.
А вообще я с автором согласен, лучше что-то чем ничего.