Comments 15
Тема котов не раскрыта…
в первом примере все таки nextbox, а не nextcat. и да, тема котов не раскрыта )
Простите, а чем Вам collections.deque не угодил?
А как добавить в середину? (В статье этого использования нет, но в целом это свойство, которое отличает linked list от deque)
Например, с помощью deque.insert?
А какой великий смысл придумывать свои названия функций вместо стандартных?
contains вместо __contains__
get вместо __getitem__
addToEnd вместо append
removeBox вместо remove
contains вместо __contains__
get вместо __getitem__
addToEnd вместо append
removeBox вместо remove
Наверно, может быть, в учебных целях?..
Но тут я с вами согласен. Мне кажется автору стоило сделать еще один шаг и реализовать правильную библиотеку. А в идеале — вообще опубликовать на гитхабе как полностью оформленную библиотеку с тестами. Можно даже как отдельную статью сделать и это новичкам принесёт куда больше практической пользы, чем даже знакомство с этой структурой данных.
Не помешали бы также тесты производительности по сравнению с штатными списком и деком.
Ну и пару придирок вдогонку:
Со всем этим багажом автора с руками оторвёт любая компания, которая набирает джунов.
Но тут я с вами согласен. Мне кажется автору стоило сделать еще один шаг и реализовать правильную библиотеку. А в идеале — вообще опубликовать на гитхабе как полностью оформленную библиотеку с тестами. Можно даже как отдельную статью сделать и это новичкам принесёт куда больше практической пользы, чем даже знакомство с этой структурой данных.
Не помешали бы также тесты производительности по сравнению с штатными списком и деком.
Ну и пару придирок вдогонку:
- автору стоило использовать __slots__
- имеет смысл сделать «ящики» неизменяемыми (immutable), ла еще и на основе typing.NamedTuple. Будет боле по-питоновски.
- как выше уже намекнули, хорошо бы использовать «магические» методы
- Не нужно лениться делать нормальные __repr__ и __init__
- полезно оформить в пакет, прописать зависимости от версии питона,
- сделать тесты
- сделать итератор по элементам
- хранить в контейнере ссылку на последний элемент тоже. Это O(1) по памяти, но делает вставку в конец тоже O(1), а сейчас O(N). Как-то нелогично же.
- Для собственного развития автора реализовать бы такую же по свойствам структуру на основе словаря, но с бонусом в O(1) для вставки в любое место связного списка. У вас-то сейчас O(N)/
- Можно сделать ту же структуру на основе бинарного дерева. Посравнивать производительность получившихся структур данных.
Со всем этим багажом автора с руками оторвёт любая компания, которая набирает джунов.
Мне кажется реализация не соответствует изначальному описанию
По факту в узле есть его значение, а также две ссылки – на предыдущий и на последующий узлы.
При этом в реализации есть только одна ссылка — на следующий узел.
class Box:
def __init__ (self,cat = None):
self.cat = cat
self.nextcat = NoneИ еще неплохо было бы пройтись каким-нибудь валидатором для pep8. Где-то пробел пропущен, где-то отступы отличаются даже в пределах одной функции.
Ну что вы придираетесь? Автор, наверно, в первый раз что-то на питоне написал и уже хочет нас чему-нибудь полезному научить, а вы просто неблагодарный сноб=). Похвальный альтруизм должен вызывать у вас улыбку. Шутки шутками, а лучше так, чем <что-нибудь плохое> в <неподобающее для этого время и месте> делать.
>Python очень удобный и многогранный язык,
>но по умолчанию не имеет такой структуры данных как связный список или LinkedList.
И это ещё один плюс :)
>но по умолчанию не имеет такой структуры данных как связный список или LinkedList.
И это ещё один плюс :)
А что в питоне нет готовой реализации связного списка?
Sign up to leave a comment.
Связный список на Python: Коты в коробках