Деньги иностранные потому что, киви это агент, который распоряжается рублями апворка. По закону надо проходить. А любые махинации могут встать в 60% штрафа.
Уже был прецендент, когда с одного из операторов взыскали больше 10 млн. украденых денег. Человек был долго за границей и у него украли все деньги путем смены владельца сим. карты.
Суд посчитал, что оператор обязан возместить обытки, так что этот вариант тоже иногда рабочий.
Я не очень понимаю причем здесь налоговое резиденство, оно про про уплату налогов с доходов полученных за границей, например со сдачи нежвижимости или наёмной работы на кого-то.
Даже если вы ИП, а не ООО, то налог на прибыль надо платить, пока вы не снялись с регистрации в России. Как только вы снялись с регистрации, вы потеряли статус легальности работы на Upwork. Ну а в большинстве стран работать как физ. лицо в иностранному гражданину на Upwork будет нельзя, нужно будет фирму открывать. Нельзя просто зависнуть где-то между двух стран и ничего не платить, если соблюдать все правила легальности. Мировая практика такова, что работая из условного Таиланда удаленно на Upwork, по закону вам нужно легализовывать это в Таиланде, хоть так никто и не делает.
Есть ещё один интересный источник памяти — её снимают со старых и убитых телефонов, иногда можно даже флешки с памью от айфонов найти и это не редкость.
Новички обычно не интересуются тем, как это работает внутри. Статья скорее для опытных Python программистов, по своему опыту могу сказать, что большинство не знает как работают вирт. окружения внутри. Чтобы программировать на Python не обязательно знать как в нём всё внутри работает, так же и с окружениями.
Это просто занимательная статистика, не более, некоторые мои коллеги даже близко не представляли количество выделяемых объектов в Python. Новички в Python, которые пришли из низкоуровневых языков по типу C/C++ тоже удивляются таким цифрам.
Ну и ещё один пример, почему динамические языки могут быть медленными.
Лучше использовать стандартный REPL питона для таких тестов, IPython слишком умный. Пока вы печайте код он сам много всяких внутренних стуктур создает и мог перехватить свободный кортеж раньше. Особенно когда вы автодополнение используйте.
Будет, вот только зачастую, люди не связанные с низкоуровневыми языками, не могут быстро сообразить ответ. Редко пригождается и зачастую не даёт прибавки по скорости.
Список сначала создается пустым, а уже потом туда добавляется элемент. Вы можете посмотреть байткод данного выражения или убедится что CPython переиспользует пыстые списки в его исходниках :)
In [3]: def test():
...: a = [1,]
...:
In [4]: dis.dis(test)
2 0 LOAD_CONST 1 (1)
2 BUILD_LIST 1
4 STORE_FAST 0 (a)
6 LOAD_CONST 0 (None)
8 RETURN_VALUE
Есть конечно, они связным списком хранятся и не так много занимают. В Python есть куча мест, где память намного больше используется, ради оптимизации скорости. Это же не C, где каждый байт экономят.
Я имел ввиду, что компилируемые языки используют CPython C API, в котором при работе с объектами нужно вручную вызывать определенные функции, которые работают со счетчиками, захватывают GIL и т.д. Оставить подсчет ссылок в нативном коде наверное можно, но это будет хак и не решит всех проблем, такое никто не пропустит в Python. Проще начать с чистого листа и выпустить Python 4.
Текущая модель работы с CPython просто не позволяет изменить многие моменты не ломая кучу библиотек (даже тех, которые написаны на чистом Python).
По поводу почему такая ситуация сложилась — тут всё просто, Python уже почти 30 лет, многие вещи проектировались в 90х годах, тогда даже многоядерных процессоров не было. Разработчики Python считают, что нужно поддерживать обратную совместимость. Ну а для полноценного JIT Python непредназначен, уж слишком он динамический сейчас.
Мне кажется всё опять упирается в API, в котором десятки лет четкие инструкции и порядок действий как работать с объектами, многие библиотеки просто сломаются. К тому же это может сильно замедлить работу (среднестатистическому скрипту потребуется более 10 000 atomic счетчиков), при этом не решает всех проблем.
В случае с Python этот метод местами мешает ему, это одна из причин почему до сих пор никто не может избавится от GIL. Если убрать подсчет ссылок, то сразу сломается всё API, которое используют библиотеки, написанные с использованием компилиуремых языков (по сути любые компилируемые модули для питона). Из-за подсчета ссылок любое действие над объектом должно быть безопасным, т.к. постоянно меняется счетчик.
Поэтому убирать в обозримом будущем его никто не будет, это сломает очень большое количество популярных библиотек.
В производительном PyPy есть сразу 6 вариантов GC, которые можно выбирать отталкиваясь от задачи. Они сразу пошли по пути отказа от стандартного API CPython.
Суд посчитал, что оператор обязан возместить обытки, так что этот вариант тоже иногда рабочий.
Даже если вы ИП, а не ООО, то налог на прибыль надо платить, пока вы не снялись с регистрации в России. Как только вы снялись с регистрации, вы потеряли статус легальности работы на Upwork. Ну а в большинстве стран работать как физ. лицо в иностранному гражданину на Upwork будет нельзя, нужно будет фирму открывать. Нельзя просто зависнуть где-то между двух стран и ничего не платить, если соблюдать все правила легальности. Мировая практика такова, что работая из условного Таиланда удаленно на Upwork, по закону вам нужно легализовывать это в Таиланде, хоть так никто и не делает.
Ну и ещё один пример, почему динамические языки могут быть медленными.
Я эти оптимизации не из головы взял, а в коде CPython подсмотрел, поэтому они точно существуют. github.com/python/cpython/blob/e271ca78e37a502b3dc1036f824aa3999efcd56b/Objects/tupleobject.c#L79
Текущая модель работы с CPython просто не позволяет изменить многие моменты не ломая кучу библиотек (даже тех, которые написаны на чистом Python).
По поводу почему такая ситуация сложилась — тут всё просто, Python уже почти 30 лет, многие вещи проектировались в 90х годах, тогда даже многоядерных процессоров не было. Разработчики Python считают, что нужно поддерживать обратную совместимость. Ну а для полноценного JIT Python непредназначен, уж слишком он динамический сейчас.
В случае с Python этот метод местами мешает ему, это одна из причин почему до сих пор никто не может избавится от GIL. Если убрать подсчет ссылок, то сразу сломается всё API, которое используют библиотеки, написанные с использованием компилиуремых языков (по сути любые компилируемые модули для питона). Из-за подсчета ссылок любое действие над объектом должно быть безопасным, т.к. постоянно меняется счетчик.
Поэтому убирать в обозримом будущем его никто не будет, это сломает очень большое количество популярных библиотек.
В производительном PyPy есть сразу 6 вариантов GC, которые можно выбирать отталкиваясь от задачи. Они сразу пошли по пути отказа от стандартного API CPython.