То вывело бы от 0 до 9

наоборот

в питоне всегда передача по ссылке же

А выведет десять девяток

я эту задачу на собеседованиях задаю часто, да :)

А в джавочке например такой финт ушами не пройдет

Так это late-binding называется

в питоне всегда передача по ссылке же

в питоне передача по значению всегда. Просто передаются ссылки

и еще прошу вставить в код три символа, чтобы его исправить

Python’s closures are late binding. This means that the values of variables used in closures are looked up at the time the inner function is called.

От этого они не перестают быть кложурами

в питоне передача по значению всегда. Просто передаются ссылки

те же яйца, только в профиль

Связывание — это ок. Я о том, что эта переменная в условии фора. И более того. Она доступна за его пределами

Так что. Не создает

и еще прошу вставить в код три символа, чтобы его исправить

Один?

А. Надо присвоить, придется три

Один?

не, один не прокатит

те же яйца, только в профиль

Нет, не те же. def foo(x): x.append(42) print "foo1", x def bar(x): x = x + [100500] print "foo2", x y = ["hello", "world"] foo(y) print "main", y bar(y) print "main", y

Нет, не те же. def foo(x): x.append(42) print "foo1", x def bar(x): x = x + [100500] print "foo2", x y = ["hello", "world"] foo(y) print "main", y bar(y) print "main", y

если бы была передача по ссылке, то не было бы разницы особой между foo() и bar()

Второе это extend

Тут ещё можно начать разглагольствовать о том что x = 2 def f(): print(x) def g(): print(x) x = 5 Функция g() упадет на принте

если бы была передача по ссылке, то не было бы разницы особой между foo() и bar()

так наоборот же, как раз по ссылке все так бы и было, ибо во втором случае ты присваиваешь

конструктор копирования же, если говорить в терминах С++

Но в общем, как любой нормальный старый язык, питон — ужасное говно и набор костылей. Сомнительных. И если копать глубже, становится стремительно хуже. Например, вызов деструктора объектов не гарантируется. Течёт (!) рекурсия (!!) нестед функций. Это вообще адище

https://jeffknupp.com/blog/2012/11/13/is-python-callbyvalue-or-callbyreference-neither/

? так, потные руки от питона убрал ??

конструктор копирования же, если говорить в терминах С++

Ещё один ад) Но уже в друглм языке

Но в общем, как любой нормальный старый язык, питон — ужасное говно и набор костылей. Сомнительных. И если копать глубже, становится стремительно хуже. Например, вызов деструктора объектов не гарантируется. Течёт (!) рекурсия (!!) нестед функций. Это вообще адище

> Например, вызов деструктора объектов не гарантируется. например, в питоне нет деструктора объектов в принципе

а про рекурсию в питоне мы уже как-то обсуждали, что она в текущем виде бесполезна)

> Например, вызов деструктора объектов не гарантируется. например, в питоне нет деструктора объектов в принципе

object.__del__(self) Called when the instance is about to be destroyed. This is also called a destructor.

> Например, вызов деструктора объектов не гарантируется. например, в питоне нет деструктора объектов в принципе

Ну, метод есть. Так то жопа есть а слова нет?

object.__del__(self) Called when the instance is about to be destroyed. This is also called a destructor.

"This is also called a destructor." - это не совсем верно

это просто коллбэк

а про рекурсию в питоне мы уже как-то обсуждали, что она в текущем виде бесполезна)

Да это ладно. Она течёт. Я не уверен, что это пофиксили. Ликает, понимаешь, рекурсивный вызов любой вложенной функции

с деструкторами в том же C++ он связан чуть более, чем никак

Да это ладно. Она течёт. Я не уверен, что это пофиксили. Ликает, понимаешь, рекурсивный вызов любой вложенной функции

не знаю, первый раз от тебя это услышал

течет?

не знаю, первый раз от тебя это услышал

I learned it hard way:) Мы сначала нашли мемори лик, потом долго курили где, а потом нашли баг в 2.7 питоне. Что-то такое def f1(): def f2(): while <condition>: f2() Течёт до перезапуска интерпретатора

с деструкторами в том же C++ он связан чуть более, чем никак

ну прям уж так и не связан

конечно же связан, хотя довольно разные вещи

В общем, поливать говном питон кто-кто, а питонщики могут долго и со вкусом)

ну прям уж так и не связан

чуть более, чем никак :) я не говорил, что совсем "никак"

ок, fair enough :)

но в C++ GC нет в принципе, так что не совсем корректное сравнение

В общем, поливать говном питон кто-кто, а питонщики могут долго и со вкусом)

Что, впрочем, не мешает писать на нем мегабайты кода)

I learned it hard way:) Мы сначала нашли мемори лик, потом долго курили где, а потом нашли баг в 2.7 питоне. Что-то такое def f1(): def f2(): while <condition>: f2() Течёт до перезапуска интерпретатора

так а что именно течет-то?

меня вот в исходниках питона удивило злоупотребление словом register

так а что именно течет-то?

Нагуглить надо, а мне чето лень с телефона

ибо все современные компиляторы либо его игнорируют совсем, либо гораздо лучше оптимизируют без него

А ещё дефолтный питон под Винду собран без использования winsock2 еррор-кодов. Это уже больше косяк разработчиков либ, конечно, но если вдруг у тебя ембеддед питон и ты захочешь включить как надо, то с вероятностью 99% при попытке переслать в сокет что-то большое упадешь на WSAEWOULDBLOCK

Я могу долго)

А ещё дефолтный питон под Винду собран без использования winsock2 еррор-кодов. Это уже больше косяк разработчиков либ, конечно, но если вдруг у тебя ембеддед питон и ты захочешь включить как надо, то с вероятностью 99% при попытке переслать в сокет что-то большое упадешь на WSAEWOULDBLOCK

Потому что его никто не ждет

хз, если правильно считать количество ссылок на объект то __del__ никогда не подводит

Вообще по идее можно любой язык долго и со вкусом обмазывать экскрементами.

Лишь брейнфак идеален. :)

хз, если правильно считать количество ссылок на объект то __del__ никогда не подводит

Считай не считай, у него в документации английским по белому написано что тебе никто не гарантирует что оно выполнится

Лишь брейнфак идеален. :)

Не. Скалочка без ООП и растик пока ниче так

А как растик устроен? На каких принципах?

ибо все современные компиляторы либо его игнорируют совсем, либо гораздо лучше оптимизируют без него

Есть версии зачем?

А и ещё. Кстати Это уже детали реализации питона, но ты не можешь заоверрайдить len() потому что integer is required

И __contains__

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

Считай не считай, у него в документации английским по белому написано что тебе никто не гарантирует что оно выполнится

кхм, это в каком месте так написано?

а вот дальше уже компилятор может как угодно это игнорить - но раз адрес нигде не берется, то может и действительно в регистр засунуть

ERROR: S client not available

There is a reason actually. The mere fact that you cannot take a address of the variable yields some optimization opportunities: the compiler can prove that the variable will not be aliased

кхм, это в каком месте так написано?

Там где описан __del__

Aragaer, спасибо, не знал про это

Там БОЛЬШОЙ варнинг

Warning Due to the precarious circumstances under which __del__() methods are invoked, exceptions that occur during their execution are ignored, and a warning is printed to sys.stderr instead. Also, when __del__() is invoked in response to a module being deleted (e.g., when execution of the program is done), other globals referenced by the __del__() method may already have been deleted or in the process of being torn down (e.g. the import machinery shutting down). For this reason, __del__() methods should do the absolute minimum needed to maintain external invariants. Starting with version 1.5, Python guarantees that globals whose name begins with a single underscore are deleted from their module before other globals are deleted; if no other references to such globals exist, this may help in assuring that imported modules are still available at the time when the __del__() method is called.

It is not guaranteed that __del__() methods are called for objects that still exist when the interpreter exits. И вот в самом описании

так тут смысл то в другом

Смысл примерно такой. Рассказываю жизненную охуительную историю. Если вдруг тебе придет в голову не очень здравая идея сделать объект tmp файла и создать его в init и удалить в del - то неожиданно может оказаться, что по выходу из интерпретатора del не успеет выполнится. И твой файл не удалится

я устал экранировать)

Хотя вообще так, конечно, писать не надо:)

казалось бы, зачем придумали __enter__ и __exit__?

это понятно, но ведь "дел" не для таких вещей!

казалось бы, зачем придумали __enter__ и __exit__?

+

Ну вот я об этом и говорю, что он _может_ не выполнится

Ну да ладно. Хватит, пойду поиграю в видеоигры и завтра пойду опять писать на питоне:)

хз, если правильно считать количество ссылок на объект то __del__ никогда не подводит

обычно результаты рефкаунтера людей сильно удивляют

Смысл примерно такой. Рассказываю жизненную охуительную историю. Если вдруг тебе придет в голову не очень здравая идея сделать объект tmp файла и создать его в init и удалить в del - то неожиданно может оказаться, что по выходу из интерпретатора del не успеет выполнится. И твой файл не удалится

ну логично, поэтому придумали with

There is a reason actually. The mere fact that you cannot take a address of the variable yields some optimization opportunities: the compiler can prove that the variable will not be aliased

ну вообще компилятор обычно без подсказок лучше справляется

Что-то asyncio как рак: где-то появился и дальше расползается по коду

Что-то asyncio как рак: где-то появился и дальше расползается по коду

прямо как жорутины в жо

ЖО

прямо как жорутины в жо

Где?

Где?

в Go

прямо как жорутины в жо

Нет.

Запусти в короутине while 1: random.random()

Запусти в короутине while 1: random.random()

зачем?

В гошечке оно не завесит вообще все

ну так в гошечке потоки же, где надо

А в asyncio - это верная смерть

ну так в гошечке потоки же, где надо

Нет, там пул потоков же

Запусти в короутине while 1: random.random()

вот был бы await random.random() и не было бы такой проблемы

вот был бы await random.random() и не было бы такой проблемы

Тююю... Ну так этого нет