Почему списки Python не создают копии аргументов, поэтому реальные объекты не могут быть видоизменены?

В этом выражении:

[d.pop() for _ in range(len(d))]

какую переменную вы хотите неявно скопировать или скопировать? Единственная переменная здесь с любым специальным статусом в понимании - _, который не является тем, который вы хотите защитить.

Я не вижу, как вы могли бы использовать семантику понимания списков, которая могла бы как-то идентифицировать все изменяемые переменные и каким-то образом их неявным образом скопировать. Или знать, что .pop() изменяет свой объект?

Вы упоминаете функциональные языки, но они выполняют то, что вы хотите, делая все переменные неизменными. Python просто не разработан таким образом.

Почему это должно создать (возможно, очень дорогостоящую) копию, когда идиоматический код не будет иметь побочных эффектов? И почему бы (редкие, но существующие) случаи использования, когда желательны побочные эффекты (и нормально) запрещено?

Python - это, прежде всего, императивный язык. Мотивируемое состояние не только разрешено, но и важно - да, списки понятий предназначены для того, чтобы быть чистыми, но если бы это было соблюдено, это было бы асинхронно с семантикой остальной части языка. Итак, d.pop() мутирует d, но только если это не в понимании списка и если звезды правы? Это было бы бессмысленно. Вы свободны (и предположили) не использовать его, но никто не собирается устанавливать больше правил в камне и сделать функцию более сложной - идиоматический код (и что единственный код, который должен заботиться о ;)), не нужно такое правило. Он делает это в любом случае и при необходимости делает иначе.

d не копируется, потому что вы не копировали его, а списки изменяемы, а pop выполняет управление списком по контракту.

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

>>> x = (1, 2, 3, 4)
>>> type(x)
<type 'tuple'>
>>> x.pop()
AttributeError: 'tuple' object has no attribute 'pop'

Почему выгодно иметь список comps ведут себя точно так же, как для циклов,

Потому что это наименее удивительно.

вместо того, чтобы вести себя как функции (с локальной областью)?

О чем ты говоришь? Функции могут мутировать свои аргументы:

>>> def mutate(d):
...     d.pop()
... 
>>> d = [1, 2, 3, 4, 5]
>>> mutate(d)
>>> d
[1, 2, 3, 4]

Я не вижу несогласованности вообще.

То, что вы, похоже, не узнаете, это то, что Python не является функциональным языком. Это императивный язык, который имеет несколько функциональных функций. Python позволяет изменять объекты. Если вы не хотите, чтобы они мутировали, просто не вызывайте методы типа list.pop, которые документированы для их изменения.

Кажется, вы неправильно понимаете функции:

def fun(lst):
    for _ in range(len(lst)):
        lst.pop()

будет иметь тот же эффект, что и

(lst.pop() for _ in range(len(lst)))

Это потому, что lst не является "списком", а ссылкой на него. Когда вы передаете эту ссылку, она остается указателем на тот же список. Если вы хотите скопировать список, просто используйте lst[:]. Если вы хотите скопировать его содержимое, используйте copy.deepcopy из модуля copy.

Если я думаю о вашем "понимании списка", он сам по себе "неспокойный". Вы ссылаетесь на d.pop() на d, и вы фактически не ссылаетесь на список в "понимании списка". Таким образом, на самом деле вы злоупотребляете пониманием списка для простого цикла for, используя измененную переменную '_', которую вы не используете для того, что вы на самом деле делаете или собираете в этом выражении: 'd.pop()'. Метод pop() применяется к d. И не имеет ничего общего с _ или с диапазоном (len (d)), который создает только другой список, используя длину d. Методы списков мутируют сам список. Таким образом, "логично", что d изменяется с помощью применения этого метода.

Как ответил Алекс Мартелли, d [:: - 1] делает то, что это выражение должно делать в "питоническом" способе.

Why is d not copied, and then the copied lexically-scoped version not mutated (and then lost)?

Поскольку python является объектно-ориентированным языком программирования, и это будет невероятно плохая идея. Все это объект.

Что заставляет вас думать, что можно создать "лексически скопированные копии" произвольных объектов?

Возможность вызова pop на объект не означает, что его можно скопировать. Он может получить доступ к дескриптору файла, сетевому сокету или очереди команд для космического зонда, вращающегося вокруг Сатурна.

Why is it advantageous to have list comps behave exactly like for loops, rather than behave more like functions (with local scope)?

• Потому что он создает сжатый, читаемый код.
• Как отмечали все остальные, функции не работают так, как вы думаете, что они делают. Они также не делают эту "лексически скопированную копию". Я думаю, что вы запутались в локальном задании.

Я рекомендую прочитать статьи здесь: http://www.cafepy.com/article/python_types_and_objects/python_types_and_objects.html

Они очень информативны в отношении того, как работает python.

Вы говорите, что хотите, чтобы методы велись по-разному в зависимости от контекста исполнения? Звучит очень опасно для меня.

Хорошо, что метод, называемый объектом Python, всегда будет делать то же самое - я был бы обеспокоен использованием языка, где вызов метода внутри какой-то синтаксической конструкции приводил к тому, что он вел себя по-другому.

Всегда существует способ не мутировать list при использовании списков. Но вы можете мутировать list тоже, если это то, что вы хотите. В вашем случае, например:

c = [a for a in reversed(d)]
c = d[::-1]
c = [d[a] for a in xrange(len(d)-1, -1, -1)]

все вы получите обратную копию list. В то время как

d.reverse()

изменит list на место.

Конечно, есть (например, обработка очереди). Но ясно, что вы показали, это не одно.

Python, как и любой язык программирования, который стоит использовать, делает именно то, что вы ему рассказываете, не больше и не меньше. Если вы хотите, чтобы он сделал что-то еще, тогда скажите ему сделать что-то еще.

Python не является функциональным языком и никогда не будет. Поэтому, когда вы используете понимание списка, вы можете изменить состояние несвязанных структур данных. Это не может быть разумно предотвращено, и такие меры, как тот, который вы описали, помогут только конкретному случаю, который вы выделили.

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

Хотя, я полагаю, если список, который вы выходите из этого примера, представляет собой очередь, которую можно добавить в код обработки очереди (то есть нечто гораздо более сложное, чем d.pop()) или другим потоком, затем код это своего рода разумный способ сделать что-то. Хотя я действительно думаю, что это должен быть цикл, а не понимание списка.

dan04 имеет правильный ответ, а для сравнения здесь немного Haskell...

[print s | s <- ["foo", "bar", "baz"]]

Здесь у вас есть побочный эффект (печать) прямо в середине понимания списка в Haskell. Haskell ленив, поэтому вы должны явно запустить его с помощью sequence_:

main = sequence_ [print s | s <- ["foo", "bar", "baz"]]

Но это практически то же самое, что и Python

_ = list(print(s) for s in ["foo", "baz", "baz"])

За исключением того, что Haskell обертывает идиому _ = list... в функции с именем sequence_.

Смысл списка не имеет ничего общего с предотвращением побочных эффектов. Это просто неожиданно, чтобы увидеть их там. И вы вряд ли можете получить больше "функциональных", чем Haskell, поэтому ответ "Python - это императивный язык" в этом контексте не совсем прав.

Я не уверен, что вы спрашиваете. Возможно, вы спрашиваете, должен ли d.pop() возвращать копию вместо того, чтобы мутировать себя. (Это не имеет ничего общего с пониманием списков.) Ответ на этот вопрос, конечно, не таков: это превратило бы его из операции O (1) в O (n), что было бы катастрофическим недостатком дизайна.

Что касается понимания списков, ничто не останавливает выражения внутри них от вызова функций с побочными эффектами. Это не ошибка списков, если вы их неправильно используете. Это не проблема языкового дизайна, чтобы заставить программистов не путать вещи.