$ ipython3
Python 3.4.3 (default, Jul 28 2015, 18:24:59)
Type "copyright", "credits" or "license" for more information.
IPython 1.2.1 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help -> Python's own help system.
object? -> Details about 'object', use 'object??' for extra details.
In [1]: def foo():
...: def bar():
...: pass
...: return bar
...:
In [2]: id(foo())
Out[2]: 3052627404
In [3]: id(foo())
Out[3]: 3052627188
In [4]: foo() is foo()
Out[4]: False
В питоне тебе придется считать отступы там, где в большинстве других популярных языков ты будешь считать парные скобки, что ничуть не легче и не проще. А вообще ты прав: не изучая любой язык, ты максимум можешь менять строковые и числовые литералы.
То что def-statement возвращает новую функцию это сложная семантика?
Как работает оператор == написано в python data model (как и про многое другое). Но если тебе не нравится функция сравнения то ты можешь это легко изменить, вплоть до сравнения байткода (f.__code__.co_code) и, эээ, переменных в замыкании (f.__closure__) итд итп.
Мы уже обсуждали это на примере типов данных.
Да, я по-прежнему не разделяю твою точку зрения о том что весь мир это массивы, хэшы, некие скаляры и ещё парочка сущностей на которые хватило знаков в ascii-таблице.
Сделай foo1 =foo(); foo2 = foo(); print(id(foo1), id(foo2)) и ты поймёшь что не так. В документации к id сказано что её значение валидно только на время жизни объекта.
def-statement возвращает новую функцию это сложная семантика?
Нет.
Да, я по-прежнему не разделяю твою точку зрения о том что весь мир это массивы, хэшы, некие скаляры и ещё парочка сущностей на которые хватило знаков в ascii-таблице.
У меня вообще дурная привычка писать вещи типа open(filename, 'w').write(data) во всяких наколенных скриптах.
Я уже столкнулся, что, например, если в cpython сборщик мусора их вовремя собирает и закрывает, то в толи jython толи ironpython это происходит не сразу, а непонятно когда, если gc не дергать вручную.
Известные грабли на стороне libc. Просто всегда делай with open(file) as fd: fd.write() и всё будет хорошо. Либо страдать с flush() что я всегда находил отвратительным.
Да никто с этим не спорит. Дизайн любого языка это всегда trade-off между простотой, логичностью, безопасностью, совместимостю с предыдущими версиями, скоростью и ещё кучей параметров. Идеальный ЯП невозможен потому что есть противоречивые требования. Но я утверждаю что в питоне достигнут неплохой баланс.
И да, питон не особо простой язык. Он логичный, он проще многих других, но сюрпризы гарантированы если не читать документацию (особенно data model, gc, threading ...).
Но я утверждаю что в питоне достигнут неплохой баланс.
В головах питонистов этот баланс. Думаю каждый из нас, интуитивно представляет себе где можно лучше и очевиднее чем есть. Но так как создание подобного инструмента большой труд - мы вынуждены искать точки соприкосновения, то что нам ближе, собираться в группы, подстраиваться под реалии и т.д.
«Ясность», «простота» - становятся мантрами в устах питонистов, когда это начинает касаться _не_ синтаксиса. Что предосудительного в том, чтобы сказать об этом? Будь я хоть понифаг, моя личность здесь до%;3ды.
Что предосудительного в том, чтобы сказать об этом?
Так ты и не говоришь, пока кроме попыток жалко потролировать не было. И странное нежелание ответить на простой вопрос только подтверждает несерьезность.
Чтобы убедиться в обсуждаемом простом частном случае, можно тупо составить таблицу истинности. False — это пустое множество, то есть {} (пусть 0), True — это множество из одного элемента {{}} (пусть 1). Степень A^B — это множество функций из A в B. Сколько функций существует из 1 в 1? Одна, то есть 1, True. Сколько функций существует из множества 1 в 0. Нисколько, то есть 0, False. И т.д. Получается чистой воды таблица истинности импликации.
Немного другим ракурсом может служить экспонента в конечном поле порядка 2. Результат будет точно таким же, конечно.
Догнал что ты имел ввиду. Да, пожалуй можно было бы добавить какой-нибудь __real_iadd__, который на уровне интерфейса гарантирует, что возвращаемое значение это исходный объект.
На самом деле я подразумевал другое. Вот есть конструктор тапла
a = ([],)
Если бы язык имел настоящую поддержку немутабельных объектов, то можно было бы сразу понять что список мутабельный и такой тапл строить не нужно. В текущей семантике тапл выходит каким-то несуразным сложным типом.
С одной стороны он немутабельный, предполагается что от него можно брать hash() и использовать в качестве сложного ключа в контейнерах. Но с другой - можно сделать тапл со списком (или любым иным мутабельным объектом) и нарваться на проблему с «+=» и невозможностью посчитать его хэш
>>> hash((1,[]))
Traceback (most recent call last):
File "<input>", line 1, in <module>
TypeError: unhashable type: 'list'
Отдельный __real_iadd__() не нужен, достаточно было бы таплу реализовать __setitem__() и тупо проверять в нём что новый объект точно такой же как и был до этого.
как ни странно питон проще ибо в нём меньше вещей к которым привыкать нужно(либо которые некритично прошиваются утятам )
всё идентификаторы есть просто имена — составляет больше сложностей для людей с паскаля/си/фортрана чем для новичков ибо
в последних всегда есть набор имён которые в компайл-тайме замещаются обьектами а есть те имена которые в рантайме.
например в сишке отличие между a[] и *p ровно в том что a - не обязано быть адресом отдельно хранимым в переменой а может быть при компиляции зашита адрессом самого массива. — похожая фигна всплывает почти во всех компилируемых.
был вон один язык где имя всегда было l-value поэтому каждый раз нужно было писать .имя для получения его r-value - однако оно(язык такой) не взлетело ибо пользователям(программистам) было неудобно.
Но зачем после выполнения += вызывать __setitem__?
Заранее не известно какой объект будет после +=. Объект может остаться прежним, может создаться новый или вообще даже может быть объект другого типа. Например
>>> a = 1
>>> type(a)
<type 'int'>
>>> a += 1.
>>> type(a)
<type 'float'>
тикл вообще не язык :) (т.е там ведь команда определяет весь синтаксис всего «выражения"до терминатора т.е при должном упорстве можно переперлить перл в тикле)
про луа - ну не так взлетело как питон - возможно что всёж автор в юж амере и в испано-сфере оказалось слишком большим штрафом vs англо-сферы питон-комьюнити.
про руби - без рельс не было бы хипстоты. был бы всё тем же излишне академичным.
-----------------
зы. всёж питон не идеал но для совсем нуба там меньше грабель которые выстреливают при проф.использовании.
и именно отсутствие „компайл-разыменования“ одна из незначительных для начинающих аксиом которая облегчает жизнь если начинающий уже продолжающий.
Я не думаю что если взять вместо питона js, php или perl что-то кардинально изменится. Почему ты решил что питон плохо подходит для твоих задач? Ну возьми свой любимый ЯП, набери «<мой любимый яп> quirks» и ужаснись. Но всё же в питоне грабли расставлены в труднодоступных местах, в отличие от многих других ЯП. Я думаю, о большинстве проблем в топике ты вообще никогда не узнаешь если будешь писать более-менее идиоматичный код.
Потом, если питон так распространён то почему бы его не изучить? Всяко лучше чем 100500 жутких DSL.
как бы ты объяснил начинающим про отступы?)) Представь, человек только начинает учить язык. Прошли введение: ввод/вывод, арифметические операции, присваивания. Подходим к ветвлениям.