Pro100Egor

Текущий стандарт начинается со слов:

ECMA-262
7ᵗʰ Edition / June 2016
ECMAScript® 2016 Language Specification

Прошлый:

Standart ECMA-262
6th Edition / June 2015
ECMAScript® 2015 Language Specification

Еще раньше начинался так:

Standard ECMA-262
5.1 Edition / June 2011
ECMAScript® Language Specification

Ходят слухи, что в те далекие времена говорили просто - Javascript, и никто особо не заморачивался. В особо запущенных случаях разделяли пятую версию и самую древнюю - третью (ее использовали особые гуру для поддержки каких-то динозавров и осликов). Но с некоторых пор стандарт стал обновляться каждый год, и к названию ECMAScript добавили год издания стандарта, но старая нумерация (3,5,6,7) осталась в сердцах людей, вот и получается, что "ES2015" - это "ES6 по старому стилю", "ES2016" - "ES7 по старому стилю".

Действительно, уважаемый. Это слишком. Вряд ли я затрону все тонкости, но попробую наметить примерный путь:

0) Пользователь вбивает в адресную строку браузера адрес сайта (нажимая клавиши на клавиатуре, которые замыкают определённую дорожку в матрице, по которой происходит определение нажатой клавиши, что через шину USB в какой-то момент передастся OS, где это поймает HID-драйвер и вызовет определённое прерывание, что OS передаст как событие/или_ещё_как в программу, которая вызовет соотвествующую функцию из API менеджера окон, которая изменит содержимое строки и в результате когда-то будет перерисован UI-элемент, а если нажат был Enter, то начнётся следующее).
1) Браузер вытащит из input'а строку с запросом и посмотрит, похоже ли это на адрес. Если да, то добавит недостающие уточнения (например, http или file протокол, порт и подобные довольно стандартные вещи). Если нет - то скорее всего создаст запрос в поисковую систему, установленную по умолчанию (я более не буду опускаться до таких бессмысленных деталей, как вызовы API-функций, иначе я буду набирать это сообщение ОЧЕНЬ долго). В любом случае на выходе мы по сути получим URL, который надо загрузить. Протокол file:// мы рассматривать не будем, ftp далеко не везде есть, https:// на не хватит вечности, так что остановимся на http, который по сути есть tcp/ip по умолчанию на 80 порту с определённым форматом общения.
2) Окей, url есть. Теперь нам нужен адрес, к которому обращаться. Так как http это tcp/ip - нам нужен ip адрес. Здесь нам помогают dns-сервера. Обычно, нормальный провайдер устанавливает у себя кэш-сервера dns, которые не обращаются по стопицот раз за vk.com к ответственному серверу com-зоны. Давайте не будем отвлекаться на то, как происходит там общение, если что - вот (вики тем хороша, что часто содержит внизу релевантные ссылки). Скажу лишь то, что на выходе мы получаем ip адрес(а).
3) Имея адрес мы можем запросить страницу. Собственно, всё что после первого слэша - это как-бы параметры для http-сервера: какую именно страницу запрашивать, он всё же не телепат. Конечно, можно было бы немного схитрить и отправить читать про tcp/ip, но ведь существует и shared-hosting. Ограничемся лишь его упоминанием. Собственно, по полученному адресу отправляется GET запрос, который и обрабатывает сервер, находящийся по полученному IP-адресу.
4) Сервер же, получив адрес, начинает распарсивать строку, медленно вытягивая нужные данные из баз-данных и настроек, выполняются сотни скриптов, иногда делается ещё не одна сотня различных запросов на другие сервера (здесь и разного вида метрики и разного вида HADOOP и т.д.). Пройдя сквозь скрипты и темплейторы в самом конце мы получаем html-страницу, готовую к употреблению. Её-то сервер и отправит в ответе (после заголовков, конечно).
5) Вот и началось самое интересное. Получив html страницу браузер начинает жутко надругаться над CPU, HDD и GPU, попутно сжирая тонны RAM и мусоря в swap. Виной всему нереальные для полного соблюдения стандарты от небезызвестной w3c.org. Для облегчения многие делают костыли, вроде webkit, а некоторые и вовсе забивают на него и пилят свой стандарт с преферансом и картёжницами (впрочем, в последнее время становиться лучше). Здесь снова начинаются сотни вызовов API ОС, windows manager'а и прочих библиотек, вроде boost, qt или libpng. В ходе работы в RAM строится макет, по которому потом строится нечто вроде PDF (тоже сильно векторный), что, потом, обрабатываясь быстрыми шейдерами на GPU, выдаётся на экран. Опять же, многое пропущено, но вряд ли кому-либо, кроме парня в свитере с оленями, действительно интересно, как работает GDI, DirectX или OpenGL.
6) Ах да, мы же забыли про тысячи js-скриптов, миллионы картинок и анимации с котиками, а также о таких дополнительных плюшках, как flash-player или java-weblets. В кратце, что js, то и flash и java - это виртуалка, со специальной архитектурой. Они, виртуалки, конечно разные (хотя flash и js довольно похожи, ещё бы - ECMAScript один и тот же). JS - самый интегрированный внутрь браузера, он же и самый медленный чисто визуально (ибо последние два имеют доступ к быстрому GPU), хотя самый быстрый в попугаях. Второй постепенно вымирает и представляет из себя, так же как и третий специальную shared-библиотеку, о которой браузер как-нибудь узнал и которой скармливает специальное содержимое помечанное специальным тегом html. Третий уже почти умер и встречается лишь изредка или в каком-нибудь энтерпрайзед со страшным legacy-базой. Ну здесь из сылок разве только гугл. Ибо сколько всего - даже не сообразишь. Да и вообще, эта тема ещё скучнее GDI, DirectX и OpenGL и к свитеру с оленями требуются ещё очки с толстенными стёклами, дающие стопицот к терпению и задроству над матаном. Если в кратце, то в случае JS, всё что было загружено в память и не думает выгружаться и формирует этакое дерево - DOM, над которым с помощью специального API и происходят модификации. При этом, перед тем как исполниться, весь JS-код компилируется, в нативный для VM байт-код. То же самое в общем-то и со вторым и третьим, разве только они не имеют доступа к DOM и организовать его - дело тех ещё костылей. Ах да, забыл ещё про Silverlight (или как оно там пишется), который сдох, не успев родиться. Так же как и Java, жив в серьёзном энтерпрайзе, не поскупившийся не "дешёвую" поддержку MS.
7) Ну... А дальше пользователь нажимает на нужную гиперссылку и всё по новой.

За кадром остались такие костыли, как ajax, websockets и прочая асинхронная ересь. С ней всё в миллионы раз сложнее. И к очкам со свитером потребуется ещё и... а чёрт их знает, что они там ещё носят. Ну да ладно, я искренне завидую тем парням (и девушкам), которые разбираются во всей этой машине. Целиком. Ибо это лишь верхушка айсберга. Разбавленная не лучшей памятью и ужасным гуглом.

P.S. Не бейте сильно за грамматические и синтаксические ошибки. Спеллчекер приказал долго жить, да и 5 утра как никак.

UPDATE
На хабр выложили неплохой перевод дающий некоторое представление, как браузер ругается над памятью и процессором. Хотя и весьма поверхностное,

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

Немного юмора

Вы уверенны в себе! Вы спокойны и расслаблены, но в тоже время остаетесь сконцентрированными. Поверхностные знания приносят вам понимание и тем самым закрепляют эти знания. Мысли направленны только на позитивный исход собеседования. На собеседовании будете отвечать уверенно и всеми своими словами, жестами, мимикой и голосом будете демонстрировать свою уверенность в своем отличном понимании предмета. Предварительно, вы в уме проиграете успешное собеседование, как талантливый актер перед пьесой. Вы представите, что к вам пришел неопытный специалист и попытаетесь ему понятно и в красках рассказать о этих самых системах.

Все у вас получится! Успехов ;)

Для стандартных типов-контейнеров (кортеж, frozenset) хэш вычисляется на основе хэшей его элементов.
Соответственно, чтобы для контейнера можно было вычислить хэш, мало одного условия неизменяемости самого объекта, нужно чтобы неизменяемыми были и все его элементы.

Поэтому кортежи (1, 2, 3) и (1, 2, [3]) оба являются неизменяемыми, но хэшируемым - только первый из них.

Вот после подбора и разбора параметров и ситуаций - результат такой:
(буду признателен если кто добавит в комментариях правки по оптимизации)
есть у нас форма с полями на типа:

<input name=domain type="text" value="{{ data.domain }}">
<input name=name type="text" value="{{data.name}}">
.......... и так далее..... вьюшка получилась универсальна - 
можно хоть сотни input добавлять прямо в шаблоне, 
главное чтоб имена были у всех разные

теперь сама вьюшка проверяет наличие input - он существует в базе то обновляет его значение - если нет еще то создает с присланными параметрами.

app.route('/setting/', methods=['GET', 'POST', 'DELETE'])
def setting():
    if not session.get('logged_in'): # проверяем залогин ли usr
        abort(404)                        
    if request.method == 'DELETE':  # Если метод HTTP = DELETE удаляем настройки для группы setting
        db.session.query(Setting).filter_by(group='setting').delete() 
        db.session.commit()
        return render_template('setting.html')
    data = {} #создаем словарь - в нем собираем данные и отправляем обратно в форму (так как разложить data = db.session.query(Setting).all() в шаблоне без переборов у меня не хватило ума... :(  , а так по-моему проще )
    if request.method == 'POST':
        for i in request.form.keys(): # обрабатываем каждый input по отдельности
            u = db.session.query(Setting).filter_by(group='setting').filter_by(key=i).first()
            if u: # если существует обновляем значением из form
                u.value = request.form[i]                 
                data[i] = request.form[i] # добавляем в словарь
            else:
                db.session.add(Setting(group='setting', key=i, value=request.form[i])) # в противном случае создаем новое поле в базе данных и добавляем обратно в словарь
                data[i] = request.form[i]
        db.session.commit() # Записать изменения в Базу данных
        return render_template('root/setting.html', data=data)  # как видите словарь ушел обратно к темплею, в указном выше примере показано как словарь раскладывается....
    u = db.session.query(Setting).filter_by(group='setting').all()   # Ну а пи простом GET запросе выгружаем все записи по группе, создаем словарь и отправляем на рендринг
    for i in u:        
        data[i.key]=i.value
    return render_template('root/setting.html', data=data)

В результате:
надо мне добавить в базу строку для хранения настройки какого-нибудь модуля
- я добавляю соответственно только в теплее очередной input в его группу
- и он сразу работает!!!!!

Кстати таблица выглядит в models.py так:

class Setting(db.Model):
    id = db.Column(db.Integer,primary_key = True)
    group = db.Column(db.String(32), nullable=False, default = 'NONE', index = True)
    key = db.Column(db.String(32), nullable=False, default = 'NONE', index = True)
    value = db.Column(db.Text, index = True)
    
    def get_id(self):
        return self.id
        
    def __unicode__(self):
        return self.id

Объекты в Python бывают изменяемые, mutable, и неизменяемые, unmutable.

Первые динамически работают с памятью, и их адрес может менятся, под вторые выделяется конкретный объем памяти и их адрес постоянен. Соответственно поэтому ключём или индексом может быть только второй тип обьектов, это кортежи, множества, строки, числа и отображения, такие объекты - hashable.

В вашем случае keys_to_delete должен был быть кортежем.