Имеются весомые контраргументы + бонус (немножно изучил вопрос).

andylars 03.06.2016 23:56

называется это @ломание обратной совместимости...
...^хэш.method[0] и ^хэш.method(0) будут делать разные по сути вещи

1.Не вижу ломания обратной совместимости. Если вы используете символы цифр, чтобы имитировать то, что нативно невозможно (массива то нет), т.е. фактически сделали "отдельную проекцию цифр" на ключи хеша, то как это не назови, но [0] - это "хак", который впрочем не ломается.

2.Структуры (модели) данных более высокого порядка, образуются путем композиции и сочетания более элементарных структур. Тут Python, пожалуй, самый опорный пример, т.к. это его конёк - атомары данных из которых собирается всё многообразие и гибкий доступ к ним. Та же парсеровская таблица, была бы просто list of tuples - список кортежей.

3.MoKo - прав, если мы имеем порядок ключей, но не можем управлять этим порядком - академически это не правильно. Или давайте тогда "восстановим справедливость" и наделаем базовых примитивов, которых нет и из-за которых все немного хромает на одну ногу:
- list (array) = список упорядоченных элементов с доступом по индексу,
- dict (hash) = ассоциативный массив с доступом по имени ключа
- tuple = кортеж (фиксация размера и порядка элементов)
- set/frozenset = (то, что добавляет операции union/intersection для dict)
- collection = композиции list,tuple,dict и set + iterator и counter = дает исчерпывающее многообразие: очереди, стеки, доступы по ключу, индексу, вставки, итерации (курсор), в общем full house.

По принципу "утиной типизации" (duck-typing) - парсеровский хеш это питоновский collection.OrderedDict, но только не оперившийся и поэтому всё еще немного "гадкий утёнок". Но всего +2 методами он даже может закрыть даже питоновскую очередь (https://docs.python.org/2/library/collections.html#collections.deque)


Бонус(!), вот как выглядит его взрослая версия - следите за руками :)
(я просто оставлю это здесь, скопировав из консоли + #допечатанные_комментарии)

~$: python

Python 2.7.3 (default, Jun 22 2015, 19:33:41) 
[GCC 4.6.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>> import collections
>>> d = collections.OrderedDict()
>>> d['KeyA'] = 'ValueA'
>>> d['KeyB'] = 'ValueB'
>>> d.items()
[('KeyA', 'ValueA'), ('KeyB', 'ValueB')]


>>> d['KeyA']                          # доступ по ключу
'ValueA'
>>> d['KeyB']
'ValueB'


>>> d.items()[0]                       # доступ по индексу 
('KeyA', 'ValueA')       
>>> d.items()[1]
('KeyB', 'ValueB')
>>> 

>>> d.keys().index('KeyA')             # получение индекса по ключу
0
>>> d.keys().index('KeyB')   
1

>>> d.keys()[0]                        # получение ключа по индексу
'KeyA'
>>> d.keys()[1]
'KeyB'


>>> d.update({'KeyA':'ValueAA'})      # добавление/изменение 
>>> d.update({'KeyC':'ValueC'})
>>> d.items()
[('KeyA', 'ValueAA'), ('KeyB', 'ValueB'), ('KeyC', 'ValueC')]



>>> d.popitem()                       # забрать последний элемент (как из стека)
('KeyC', 'ValueC')
>>> d.items()
[('KeyA', 'ValueAA'), ('KeyB', 'ValueB')]   

Поэтому, как бы смысла обсуждать теоритическую часть: "можно ли смешивать ключи и индексы" - вроде и нет, пример выше чуть более, чем убедительный, учитывая насколько широко в продакшене и в мире используется - Python 2.x

"Парсеровский хеш" сейчас по всем признакам - OrderedDict, но хромой на очевидные методы и работы с индексами, которые однозначно должен уметь, раз заявился на порядок элементов.

Я даже не агитирую за похожий, как в примере питоновский update (хотя и заикнулся, о "вставке с перетиранием", в первой версии "формализации", но легко можно "облезть без него". А вот минимальный набор из предложенных 2 методов + 2 апдейтов - существующих, это явно must have. Тем более, что закрывает так много.

Поэтому, тут только 2 варианта развития:
Или Перетанцевать всю иерархию примитивов данных (маловероятный на практике)
Или Докрутить пару методов и пару апдейтов для существующих, получив на выходе намного более полноценный и мощный инструмент (тем более, что ниша для Парсера, явно в сторону более высокуровневых абстракций, внизу ему делать нечего).

Можно еще оставить всё как есть, но тогда это уже не "развитие".

---