фактически, мы строим новый список, итерируя по старому: включаем новый элемент в список (левая часть, та что до оператора for) если выполнено некоторое условие (правая часть, та что if).
итак, enumerate возвращает список пар вида (индекс-елемента, значение-элемента). мы итерируем по нему и проверяем, если индекс текущего элемента равен индексу первого вхождения этого элемента в исходный список, дополняем новый список текущим элементом.
не должен. смотри, ты проверяешь первый элемент. он есть в хвосте и ты его пропускаешь.
тоесть ты оставляешь только последние вхождения уникальных элементов.
я сделал так:
[x for i, x in enumerate(l) if l.index(x) == i]
но это тоже жусть.
в принципе, ниче так. правда, на мой взгляд, немного скучновато.
я бы еще настоятельно рекомендовал добавить сюда такие полезности как sorted, перегон из списка пар в словарь и наоборот, а также map/zip и т.п.
по сравнению с 3.4 они угробили динамику :(
скорее всего, конечно, скоро все привыкнут, но, тем не менее, досадно.
плюс с "красивостями" имхо перебор. глаза рябит, а отключить никак.
о мелких, но раздражающих багах я вообще молчу. сырой короче релиз. очень сырой.
реальные задачи очень редко будут решаться "на чем дуще угодно". а так можно будет посмотреть насколько джуниорчик способен освоиться с (возможно, для него) новыми инструментами/технологиями.
более того, считаю, что в данном случае инструментарий стоит ограничить лишь тем, что принят в компании как стандарт. если такой практики нет, лишь тем, который используется в проекте на который джуниорчика собираются поставить.
неоднократно сталкивался с ситуацией, когда приходил в проект новый сотрудник и пытался "свою религию" навязать. зачастую инструментария который по тем или иным соображениям был ранее отвергнут.
да и, что греха таить, сам таким же был когда-то :))
дано дерево организованное списком смежности. нужно сделать выборку всего дерева с сортировкой вершин одного уровня имеющих общего родителя по некоторому ключевому аттрибуту.
при этом порядок обхода желателен префиксный, чтобы можно было без подолнительной обработки осуществить вывод.
> нужно выводить ноды то по алфавиту, то по дате добавления, то по популярности
а ну это достаточно сильно усложняет задачу. первое что пришло на ум держать несколько индексных таблиц (с внешними ключими на основные данные) в которых будет поддерживаться отношение порядка по заданному ключу (внутри ветви).
вообще надо подумать. интересная задача.
такое решается на списках смежности? правда интересно.
> (при сбое портится все дерево, а не одна ветвь). Потому использовать ее в качестве основной и единственной лично я бы не советовал.
ну это, кстати, сильный аргумент. тут я ничего добавить не могу :)
> Элементарно (ну почти:) через джойн таблицы самой на себя.
ok. есть такое дело. но в любом случае, надеюсь, вы не будете отрицать, что джойны несколько медленнее прямых выборок?
> Не могу представить себе задачу, где это понадобится. Особенно в контексте каталога.
да в том же интерфейсе редактирования каталога. ну не хочет заказчик видеть все разделы. хочет только те куда можно переместить.
> а перетряска всей таблицы для той же задачи — это хорошо и правильно?
я не утверждал, что вложенные множества идеальный вариант представления любой древовидной структуры. при большом количестве запросов на insert и update она явно не подходит. тем не менее, для реализации древовидного каталога они наиболее востребованны. здесь частота изменений в каталоге намного реже запросов на выборку в различных вариантах.
> А как насчет произвольной сортировки ветвей при выводе
очень странно. это только у меня иерархия сообщений сломалась? если что, предыдущий пост это ответ на http://habrahabr.ru/blog/php/37631.html#comment712600
фактически, мы строим новый список, итерируя по старому: включаем новый элемент в список (левая часть, та что до оператора for) если выполнено некоторое условие (правая часть, та что if).
итак, enumerate возвращает список пар вида (индекс-елемента, значение-элемента). мы итерируем по нему и проверяем, если индекс текущего элемента равен индексу первого вхождения этого элемента в исходный список, дополняем новый список текущим элементом.
[x for i, x in enumerate(l) if l.index(x) == i]
тоесть ты оставляешь только последние вхождения уникальных элементов.
я сделал так:
[x for i, x in enumerate(l) if l.index(x) == i]
но это тоже жусть.
так что, принципиально ничем не отличается.
я бы еще настоятельно рекомендовал добавить сюда такие полезности как sorted, перегон из списка пар в словарь и наоборот, а также map/zip и т.п.
мегапозитив :)
опротестовать решение как-нибудь возможно?
скорее всего, конечно, скоро все привыкнут, но, тем не менее, досадно.
плюс с "красивостями" имхо перебор. глаза рябит, а отключить никак.
о мелких, но раздражающих багах я вообще молчу. сырой короче релиз. очень сырой.
реальные задачи очень редко будут решаться "на чем дуще угодно". а так можно будет посмотреть насколько джуниорчик способен освоиться с (возможно, для него) новыми инструментами/технологиями.
более того, считаю, что в данном случае инструментарий стоит ограничить лишь тем, что принят в компании как стандарт. если такой практики нет, лишь тем, который используется в проекте на который джуниорчика собираются поставить.
неоднократно сталкивался с ситуацией, когда приходил в проект новый сотрудник и пытался "свою религию" навязать. зачастую инструментария который по тем или иным соображениям был ранее отвергнут.
да и, что греха таить, сам таким же был когда-то :))
насчет древовидной структуры поддерживаю.
слово в слово практически, только писать лень было :)
не верю! (с)
и не только позапрошлый: http://habrahabr.ru/blog/php/37631.html#comment712812
и не только мой: http://habrahabr.ru/blog/php/37631.html#comment712600
в моем понимании постановка задачи такая:
дано дерево организованное списком смежности. нужно сделать выборку всего дерева с сортировкой вершин одного уровня имеющих общего родителя по некоторому ключевому аттрибуту.
при этом порядок обхода желателен префиксный, чтобы можно было без подолнительной обработки осуществить вывод.
либо давайте уточним постановку задачи.
а ну это достаточно сильно усложняет задачу. первое что пришло на ум держать несколько индексных таблиц (с внешними ключими на основные данные) в которых будет поддерживаться отношение порядка по заданному ключу (внутри ветви).
вообще надо подумать. интересная задача.
такое решается на списках смежности? правда интересно.
> (при сбое портится все дерево, а не одна ветвь). Потому использовать ее в качестве основной и единственной лично я бы не советовал.
ну это, кстати, сильный аргумент. тут я ничего добавить не могу :)
ok. есть такое дело. но в любом случае, надеюсь, вы не будете отрицать, что джойны несколько медленнее прямых выборок?
> Не могу представить себе задачу, где это понадобится. Особенно в контексте каталога.
да в том же интерфейсе редактирования каталога. ну не хочет заказчик видеть все разделы. хочет только те куда можно переместить.
> а перетряска всей таблицы для той же задачи — это хорошо и правильно?
я не утверждал, что вложенные множества идеальный вариант представления любой древовидной структуры. при большом количестве запросов на insert и update она явно не подходит. тем не менее, для реализации древовидного каталога они наиболее востребованны. здесь частота изменений в каталоге намного реже запросов на выборку в различных вариантах.
> А как насчет произвольной сортировки ветвей при выводе
честно, не вижу здесь проблемы.
> это типичная преждевременная оптимизация
не, это грамотная архитектура :)