Javascript словарь – JAVASCRIPT перевод с английского на русский, translation English to Russian. Англо-Русский словарь компьютерных терминов

Словари / объекты — python-v-js

Стандартная структура для хранения данных с возможностью обращения по произвольному ключу (отображение) в Python называется dict (dictionary, словарь), а в JavaScript — object (объект).

my_dict = {'a': 10, 'b': 20}
my_dict['a']

10

my_dict.a

Exception: AttributeError
'dict' object has no attribute 'a'

var my_obj = {a: 10, b: 20};
my_obj['a']; 

10

my_obj.a;

10

var my_obj = {'long key': 'some value', 
               short_key: 'other value'}
my_obj['long key'];

some value

my_obj['short_key'];

other value

my_obj.short_key;

other value

 my_dict = {'a': 10, 'b': 20}
my_dict['a'] = 'hello'
my_dict['a']

'hello'

var my_obj = {a: 10, b: 20};
my_obj['a'] = 'hello';
my_obj['a'];

hello

var my_obj = {a: 10, b: 20};
my_obj.a = 'hello';
my_obj['a'];

hello

my_dict = {}
my_dict[5] = 'hello'
my_dict['5'] = 'world'
my_dict 

{5: 'hello', '5': 'world'}

var my_obj = {};
my_obj[5] = 'hello';
my_obj['5'] = 'world';
my_obj;

{ '5': 'world' }

my_obj[ ['5'] ];

world

my_dict = {'a': 10, 'b': 20}
'a' in my_dict

True

my_obj = {a: 10, b: 20};
'a' in my_obj;

true

my_dict = {'a': 10, 'b': 20}
my_dict['c']

Exception: KeyError
'c'

my_dict.get('c')

None

my_dict.get('c', 'Nothing')

'Nothing'

 my_obj = {'a': 10, 'b': 20};
my_obj['c'];

undefined

my_obj.c;

undefined

Реализация объектов-словарей, как в Javascript / Habr

>>> a.id = 42
>>> a.name = «Jon»
>>> print a
{‘id’: 42, ‘name’: ‘Jon’}

При этом, конечно же важно сохранить стандартную функциональность словаря:

>>> print «id: %(id)d, name: %(name)s» % a
id: 42, name: Jon
>>> a.keys()
[‘id’, ‘name’]

Довольно приятно, правда? Так почему бы не сделать этого средствами самого питона?

Реализация 1. В лоб.

Первое, что приходит в голову, это просто реализовать работу всех нужных нам магических методов:

class Dict(dict):
    def __getattr__(self, key):
        return self[key]
    def __setattr__(self, key, value):
        self[key] = value
    def __delattr__(self, key):
        del self[key]

Но, кажется, это не слишком pythonic. Присмотревшись немного, можно увидеть, что выполняется лишняя работа, и код можно сократить.

Реализация 2. Дао питона.

На самом деле, достаточно просто подменить одни unbound-методы другими, благо они имеют одинаковую сигнатуру:

class Dict(dict):

    __getattr__ = dict.__getitem__
    __setattr__ = dict.__setitem__
    __delattr__ = dict.__delitem__

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

Реализация 3. Маленькая магия.

class Dict(dict):
    def __new__(cls, *args, **kwargs):
        self = dict.__new__(cls, *args, **kwargs)
        self.__dict__ = self
        return self

Понимаете, что происходит? Самое интересное находится в строчке self.__dict__ = self. По-сути, наш объект является обычным словарем, так почему бы ему не быть еще и словарем атрибутов самого себя? Теперь, когда мы будем извлекать, изменять или удалять атрибут экземпляра класса Dict, эти изменения будут непосредственно отражаться на значениях в этом экземпляре как словаре, ведь по сути они стали одними и теми же сущностями.

>>> d = Dict(a = 1, b = 2, c = 3)
>>> print d
{‘a’: 1, ‘c’: 3, ‘b’: 2}
>>> print d.a == d[«a»]
True
>>> d.b = 7
>>> del d.c
>>> d.x = 4
>>> print d
{‘a’: 1, ‘x’: 4, ‘b’: 7}
>>> print d.keys(), d.items()
[‘a’, ‘x’, ‘b’] [1, 4, 7]

Вот и получилось еще одно доказательство того, как вместе с питоном можно сделать много полезного и интересного. А если понимать то, как он устроен внутри, это можно сделать еще и красиво и элегантно.
Конечно, я не создал ничего принципиально нового, но в тех проектах, где приходится работать с наполовину типизированными сущностями, мне больше не приходится выбирать между словарем и объектом, да и код стал немного чище.

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

Чем отличаются JavaScript и ECMAScript? / NIX corporate blog / Habr

Как-то мы попробовали гуглить «различие между JavaScript и ECMAScript».

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

«ECMAScript — это стандарт».
«JavaScript — это стандарт».
«ECMAScript — это спецификация».
«JavaScript — это реализация стандарта ECMAScript».
«ECMAScript — стандартизованный JavaScript».
«ECMAScript — это язык».
«JavaScript — это диалект ECMAScript».
«ECMAScript — это JavaScript».

В этой статье представлено наше понимание различий между JavaScript и ECMAScript. Статья написана для тех, кто знаком с JavaScript, но хочет получить более четкое представление о его взаимоотношениях с ECMAScript, веб-браузерами, Babel и так далее. Вы также узнаете о скриптовых языках, движках JavaScript и средах выполнения JavaScript.

Ну что, погнали.

Словарь JavaScript/ECMAScript

Ecma International

ECMA-262

ECMA-262 можно считать учётным номером ECMAScript.

ECMA-260, ECMA-261, ECMA-262. А вот и ECMAScript.

Скриптовый язык

Чтобы понять, как язык программирования становится скриптовым языком, рассмотрим команды «ходить», «бегать» и «прыгать». Их кто-то должен выполнять, например, человек, собака или персонаж видеоигры. Без выполняющего команды актера все эти «ходить», «бегать» и «прыгать» не имеют смысла. Этот набор действий аналогичен скриптовому языку, который предназначен для управления внешним объектом.

ECMAScript

Синоним: спецификация ECMAScript.

ECMAScript содержит правила, сведения и рекомендации, которые должны соблюдаться скриптовым языком, чтобы он считался совместимым с ECMAScript.

Выдержка из спецификации языка ECMAScript 2017. Документ состоит примерно из 900 страниц, если вы ищете, что почитать на досуге.

JavaScript

Это диалект языка ECMAScript.

JavaScript — мой любимый язык программирования, пропитанный ароматом кофе. ECMAScript — это спецификация, на которой он основан. Из спецификации ECMAScript вы узнаете, как создать скриптовый язык, а из документации JavaScript — как использовать скриптовый язык.

Когда люди называют JavaScript «диалектом языка ECMAScript», они имеют в виду то же самое, что и при упоминании о диалектах английского, французского или китайского языка. Диалект большую часть своего лексикона и синтаксиса наследует из родительского языка, от которого при этом заметно отличается.

Как сказано в ECMA-262, JavaScript в основном реализует спецификацию ECMAScript, но с некоторыми отличиями. Mozilla в общих чертах обрисовала свойства JavaScript, не характерные для ECMAScript:

Скриншот от 3 сентября 2017 года. Это список экспериментально проверенных характерных особенностей JavaScript, которые не являются частью ECMAScript (по крайней мере, пока).

JavaScript-движок

Синонимы: интерпретатор JavaScript, реализация JavaScript.

Для браузера JavaScript-движок — это как для человека способность понимать речь. Если опять обратиться к нашему примеру с «ходить», «бегать» и «прыгать», то JavaScript-движок — часть «объекта», который на самом деле понимает, что означают эти действия.

Эта аналогия помогает объяснить некоторые особенности браузера:

Разное быстродействие браузеров

Разная поддержка в браузерах

Говоря о поддержке в браузерах, обычно упоминают о «совместимости с ECMAScript», а не о «совместимости с JavaScript», хотя JavaScript-движки детально анализируют и выполняют… JavaScript. Звучит запутанно, позвольте объяснить.

Это часть таблицы, посвящённой браузерной поддержке ECMAScript. Версии JavaScript в ней не упоминаются.

Как вы помните, ECMAScript — это спецификация того, как может выглядеть скриптовый язык. Появление новой версии ECMAScript не означает, что у всех движков JavaScript появятся новые функции. Всё зависит от групп или организаций, которые отвечают за обновления JavaScript-движков с учётом новейшей спецификацией ECMAScript.

Поэтому разработчики, как правило, задают вопросы вроде «Какую версию ECMAScript поддерживает этот браузер?» или «Какие функции ECMAScript поддерживает этот браузер?» Они хотят знать, удалось ли Google, Mozilla и Microsoft наделить JavaScript-движки (соответственно V8, SpiderMonkey и Chakra) свойствами, описанными в последней версии ECMAScript.

Ответы на многие вопросы вы найдёте в Таблице совместимости ECMAScript.

Если выйдет новая версия ECMAScript, то в JavaScript-движках не появятся разом все нововведения. Они будут внедряться постепенно, релиз за релизом, как это видно на примере журнала изменений JavaScript в Firefox:

Какие-то части стандартов ES2015 и ES2017 были реализованы в JavaScript-движке SpiderMonkey в браузере Firefox 50. Ещё раньше были реализованы другие части ES2015 и ES2017, и это продолжилось в последующих версиях.

Среда выполнения JavaScript

Синонимы: хост-среда (Host environment).

JavaScript-скрипты могут обращаться к приложениям, потому что те предоставляют «хост-объекты» в среде выполнения. На клиентской стороне средой выполнения JavaScript будет веб-браузер, в котором становятся доступными для манипуляций такие хост-объекты, как окна и HTML-документы. Вы когда-нибудь работали с хост-объектами в виде окна или документа? Такие объекты не являются частью базового JavaScript. Это веб-API, объекты, предоставляемые браузером, действующим как хост-среда JavaScript.

На серверной стороне среда выполнения JavaScript — это Node.js. В Node.js предоставляются связанные с сервером хост-объекты, такие как файловая система, процессы и запросы.

Любопытно, что разные среды выполнения JavaScript могут использовать один и тот же JavaScript-движок. Например, V8 — это движок, используемый в двух совершенно разных средах — в Google Chrome и Node.js.

ECMAScript 6

Синонимы: ES6, ES2015 и ECMAScript 2015.

Babel

При желании, разработчики могут с помощью Babel преобразовать — транспилировать — код ES6 в функционально эквивалентную версию, использующую только функции ES5. Все основные браузеры полностью поддерживают ES5, поэтому транспилированный код будет работать без каких-либо проблем.

Ещё кое-что

Курица или яйцо

Получается, что ECMAScript основан на JavaScript, а JavaScript основан на ECMAScript.

Да, это смахивает на затёртый кинематографический штамп, когда путешественники во времени становятся своими собственными родителями. Забавно, хотя и немного странно.

Понимаем, что всё здесь сказанное немного вас позабавило, но надеемся, что вы получили пищу для размышлений. Позвольте откланяться.

Глоссарий англоязычных терминов

Этот список содержит основные англоязычные термины и их перевод, принятый в стандарте ECMAScript.

InputElementDiv	ВходнойЭлементДеления
InputElementRegExp	ВходнойЭлементРегВыр
MultiLineComment	МногострочныйКомментарий
RegExp	РегВыр
Pattern	Шаблон
Program	Программа
Expression	Выражение
Statement	Инструкция
WithStatement	ИнструкцияWith
AssignmentExpression	ВыражениеПрисваивания
ArgumentList	СписокАргументов
Identifier	Идентификатор 
Initialiser	Инициализатор
ExpressionNoIn	ВыражениеБезIn
DecimalDigit	ДесятичнаяЦифра 
DecimalDigits	ДесятичныеЦифры
LookaheadExample	ПримерПредпросмотра
LineTerminator	КонецСтроки
NonZeroDigit	НенулеваяЦифра
IdentifierName	ИмяИдентификатора
SourceCharacter	ИсходныйСимвол
WhiteSpace	Пробел
Comment	Комментарий
SingleLineComment	ОднострочныйКомментарий
MultiLineCommentChars	СимволыМногострочногоКомментария
MultiLineNotAsteriskChar	МногострочныйСимвНеЗвёздочка
PostAsteriskCommentChars	СимволыКомментарияПослеЗвёздочки
MultiLineNotForwardSlashOrAsteriskChar	МногострочныйСимвНеСлэшИлиЗвёздочка
SingleLineCommentChars	СимволыОднострочногоКомментария
SingleLineCommentChar	СимволОднострочногоКомментария
Token	Токен
Punctuator	ЗнакПрепинания
NumericLiteral	ЧисленныйЛитерал
StringLiteral	СтроковойЛитерал
ReservedWord	ЗарезервированноеСлово
Keyword	КлючевоеСлово
FutureReservedWord	ЗарезервированноеНаБудущееСлово
NullLiteral	ЛитералNull
BooleanLiteral	БулевскийЛитерал
UnicodeEscapeSequence	ЮникоднаяEscapeПоследовательность
IdentifierStart	НачалоИдентификатора
IdentifierPart	ЧастьИдентификатора
UnicodeLetter	БукваЮникода
UnicodeCombiningMark	КомбинирующийЗнакЮникода
UnicodeDigit	ЦифраЮникода
UnicodeConnectorPunctuation	СоединяющаяПунктуацияЮникода
HexDigit	ШестнадцатеричнаяЦифра
DivPunctuator	ЗнакДеления
Literal	Литерал
DecimalLiteral	ДесятичныйЛитерал
HexIntegerLiteral	ШестнадцатеричныйЦелыйЛитерал
DecimalIntegerLiteral	ДесятичныйЦелыйЛитерал
ExponentPart	ЭкспоненциальнаяЧасть
SignedInteger	ЗнаковоеЦелое
ExponentIndicator	ПризнакЭкспоЗаписи
DoubleStringCharacters	СимволыДвойнойСтроки
SingleStringCharacters	СимволыОдинарнойСтроки
DoubleStringCharacter	СимволДвойнойСтроки
SingleStringCharacter	СимволОдинарнойСтроки
EscapeSequence	EscapeПоследовательность	
CharacterEscapeSequence	СимвольнаяEscapeПоследовательность
HexEscapeSequence	ШестнадцатеричнаяEscapeПоследовательность
SingleEscapeCharacter	ОдиночныйEscapeСимвол
NonEscapeCharacter	НеEscapeСимвол
EscapeCharacter	EscapeСимвол
RegularExpressionBody	ТелоРегулярногоВыражения
RegularExpressionFlags	ФлагиРегулярногоВыражения
RegularExpressionLiteral	ЛитералРегулярногоВыражения
RegularExpressionFirstChar	ПервыйСимволРегулярногоВыражения
RegularExpressionChars	СимволыРегулярногоВыражения
RegularExpressionChar	СимволРегулярногоВыражения
NonTerminator	НеОкончание
BackslashSequence	ПоследовательностьОбрСлэш
PostfixExpression	Постфиксно

javascript — со всех языков на русский

javascript — с английского на русский

JavaScript-библиотека для обработки текстов на русском языке / Habr

Как чуден и глубок русский курлык
— Генератор постов

А ещё с небольшими затратами можно сделать какого-нибудь бестолкового чат-бота — или, как вот я, генератор постов на основе того, что вы писали на своей страничке в соцсети. Возможно, кто-то из вас уже видел это приложение — оно довольно глупое, чаще всего выдает бессмысленный и бессвязный текст, но изредка всё же дает повод улыбнуться.

Бессвязность текстов в нынешней версии «Генератора» вызвана тем, что на самом деле никакого анализа он производить не умеет. Просто в одних случаях «предсказывает» продолжение предложения по собранным биграммам, а в других — заменяет в готовом предложении некоторые слова на другие, которые заканчиваются похоже. Вот и вся начинка.

Конечно, хочется сделать что-нибудь поинтереснее. Беда в том, что модные сейчас нейросети не очень-то применимы здесь: им нужно много ресурсов, большую обучающую выборку, а в браузере у пользователя соцсети всего этого нет. Поэтому я решил изучить вопрос работы с текстами с помощью алгоритмов. К сожалению, готовых инструментов для работы с русским языком на JavaScript найти не удалось, и я решил сделать свой маленький велосипед.

На данный момент библиотека умеет две вещи: токенизацию и анализ морфологии. В некотором отдаленном будущем (но не в первой версии) предполагается реализовать синтаксический анализ и извлечение смыслов из предложений.

Обычно для этой цели используется что-нибудь типа одного вызова split по простой регулярке, но мне этого показалось мало. Например, если разделить строку по пробелам, мы потеряем сами пробелы — иногда это удобно, но не всегда. Ещё хуже, если мы захотим предварительно разбить строку по точкам, вопросительным и восклицательным знакам (надеясь выделить так предложения): мало того, что теряются конкретные знаки препинания, так ещё и точки на самом деле не всегда завершают предложения. А потом мы понимаем, что в реальных текстах могут встретиться, скажем, ссылки (и точки в них точно никакого отношения к пунктуации не имеют) и регулярка становится совсем страшной.

Az предлагает свое, не-деструктивное, решение этой задачи. Гарантируется, что после токенизации каждый символ будет принадлежать некоторому токену и только одному. Пробелы, переводы строк и прочие невидимые символы объединяются в один тип токенов, слова — в другой, пунктуация — в третий. Если все токены склеить вместе — получится в точности исходная строка.

При этом токенизатор достаточно умен, чтобы понимать, что дефис, обрамленный пробелами — это знак препинания (вероятно, на его месте подразумевалось тире), а прижатый хотя бы с одной стороны к слову — часть самого слова. Или что «habrahabr.ru» — это ссылка, а «[email protected]» — это, вероятно, емэйл (да, полная поддержка соответствующего RFC не гарантируется). #hashtag — это хэштег, user — упоминание.

И наконец — раз уж RegExp’ы для этой цели использовать не стоит — Az.Tokens умеет парсить HTML (а заодно — вики и Markdown). Точнее говоря, никакой древовидной структуры на выходе не будет, но все теги будут выделены в свои токены. Для тегов <script> и <style> сделано дополнительное исключение: их содержимое превратится в один большой токен (вы же не собирались разбивать на слова свои скрипты?).

А вот и пример обработки Markdown-разметки:

Обратите внимание, скобки в одних случаях превращаются в пунктуацию (светло-синие прямоугольники), а в других — в Markdown-разметку (показана зеленым цветом).

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

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

Каждый конкретный набор граммем у слова называется тегом. Всевозможных тегов значительно меньше, чем слов — поэтому они пронумерованы и хранятся в отдельном файле. Чтобы уметь склонять слова (а Az.Morph это тоже умеет), нужно как-то уметь менять их теги. Для этого существуют парадигмы слов: они ставят в соответствие тегам определенные префиксы и суффиксы (то есть один и тот же тег в разных парадигмах имеет разные пары префикс+суффикс). Зная парадигму слова, достаточно «откусить» от него префикс и суффикс, соответствующие текущему тегу, и добавить префикс/суффикс того тега, в который мы его хотим перевести. Как и тегов, парадигм в русском языке относительно немного — это позволяет в словаре хранить для каждого слова только пару индексов: номер парадигмы и номер тега в ней.

Вот пример: слово «крепкая» имеет тег, по-русски кратко обозначаемый как «ПРИЛ, кач жр, ед, им» — то есть это качественное прилагательное женского рода единственного числа в именительном падеже. Этому тегу (в той парадигме, которой принадлежит слово «крепкая»), соответствует пустой префикс и суффикс «-кая». Предположим, мы хотим получить из этого слова его сравнительную степень, да ещё и не обычную, а особую, с префиксом «по-»: «КОМП, кач сравн2». У неё в этой парадигме, как нетрудно догадаться, префикс «по-» и суффикс «-че». Отрезаем «-кая», добавляем «по-» и «-че» — получаем искомую форму «покрепче».

NB. Как можно заметить, под префиксами и суффиксами тут понимаются не лингвистические термины, а просто подстроки, находящиеся в начале/конце слов.

Такое вот относительно сумбурное изложение внутреннего механизма склонений в Az.Morph. По сути эта часть библиотеки — порт замечательного морфологического анализатора pymorphy2 за авторством kmike (на Хабре была пара статей об этой библиотеке). Кроме самого анализатора, рекомендую ознакомиться с его документацией — там много полезной информации, которая полностью применима и к Az тоже. Кроме того, Az использует формат словарей, аналогичный словарям pymorphy2, за исключением небольших деталей (которые позволили сделать словарь на 25% компактнее). По этой причине, увы, самостоятельно собрать их не получится — но в будущем такая возможность, конечно, появится.

Как я уже упомянул, основные словари хранятся в хитром формате DAWG (в вики есть статья о directed acyclic word graph, как об абстрактной структуре данных, но о конкретной реализации информации мало). Реализуя его поддержку в JS, я оценил фичу pymorphy2, позволяющую при поиске слова сразу проверять вариант с «ё» вместо «е» — это не дает особых потерь в производительности из-за того, что при спуске по префиксному дереву легко обойти ветви, соответствующие обеим буквам. Но мне этого показалось мало и я аналогичным образом добавил возможность нечеткого поиска слов с опечатками (то есть можно задать максимальное расстояние Дамерау-Левенштейна, на котором должно находиться искомое слово от заданного). Кроме того, можно находить «растянутые» слова — по запросам «гоооол» или «го-о-о-ол» найдется словарное «гол». Разумеется, эти особенности тоже опциональны: если вы работаете в «тепличных условиях», с грамотными, вычитанными текстами — поиск опечаток стоит запретить. А вот для написанных пользователями записей это может быть весьма актуально. В планах — заодно ловить и наиболее распространенные ошибки, не являющиеся опечатками.

Как видите, по заданному слову библиотека может вернуть разные варианты разбора из словаря. И это связано не только с опечатками: классический пример грамматической омонимии — слово «стали», которое может оказаться формой как существительного «сталь», так и глагола «стать». Чтобы решить однозначно (снять омонимию) — нужно смотреть на контекст, на соседние слова. Az.Morph этого пока не умеет (да и задача эта уже не для морфологического модуля), поэтому вернет оба варианта.

Более того: даже если в словаре не нашлось ничего подходящего, библиотека применит эвристики (называемые предсказателями или парсерами), которые смогут предположить, как слово склоняется — например, по его окончанию. Тут бы вставить весёлую историю с башорга про анализатор, считающий слово «кровать» глаголом, да одна беда — оно, конечно же, есть в словаре, и только как существительное 🙂

Впрочем, у меня нашлись свои курьёзы. Например, у слова «философски» среди прочих вариантов нашлись некие «филососки» (с исправленной опечаткой). Но удивительнее всего оказалось, что слово «мемас» стабильно разбирается как глагол (!), инфинитив у которого — «мемасти» (!!!). Не сразу получается понять, как такое вообще возможно — но такую же парадигму имеет, например, слово «пасти». Ну и формы типы «мемасём», «мемасёмте», «мемасённый», «мемасено», «мемасши», по-моему, прекрасны.

Несмотря на эти странности, обычно результаты оказываются довольно адекватными. Этому способствует то, что (как и в pymorphy2) каждому варианту присваивается оценка «правдоподобия» и они сортируются по убыванию этой оценки. Так что если делаете алгоритм побыстрее — можно брать первый вариант разбора, а если хочется точности — стоит перебрать все.

По моим грубым замерам, конкретные цифры (в браузере Chrome) примерно таковы:

• Токенизация: 0.7–1.0 млн символов в секунду
• Морфология без опечаток: 210 слов в секунду
• Морфология с опечатками: 180 слов в секунду

Кроме того, не снимается вопрос оптимизации — JS вряд ли сможет угнаться за кодом на C, но что-то улучшить наверняка можно.

Другие планы, упомянутые в статье: инструмент для самостоятельной сборки словарей, поиск слов с ошибками (т.е., скажем, чтобы для слов на «т(ь)ся» возвращался вариант и с мягким знаком, и без, а синтаксический анализатор выбирал бы правильный).

И, разумеется, я открыт вашим идеям, предложениям, багрепортам, форкам и пулреквестам.