Существует ли универсальная альтернатива классу ListDictionary?
Вы имеете os.path.exists функция:
import os.path
os.path.exists(file_path)
Это возвращается True и для файлов и для каталогов, но можно вместо этого использовать
os.path.isfile(file_path)
, чтобы протестировать, если это - файл конкретно. Это следует за символьными ссылками.
3 ответа
К сожалению, универсального эквивалента ListDictionary не существует.
Однако реализовать его не должно быть очень сложно. ListDictionary по сути работает, сохраняя связанный список пар ключ / значение и перебирая их для операций поиска. Вы можете создать ListDictionary , заключив в LinkedList несколько очень простых выражений LINQ.
Например
public class LinkedDictionary<TKey,TValue> {
private LinkedList<KeyValuePair<TKey,TValue>> _list = new LinkedList<KeyValuePair<TKey,TValue>>();
private IEqualityComparer<TKey> _comp = EqualityComparer<TKey>.Default;
public void Add(TKey key, TValue value) {
_list.Add(new KeyValuePair<TKey,TValue>(key,value));
}
public TValue Get(TKey key) {
return _list.Where(x => _comp.Equals(x.Key,key)).First().Value;
}
...
}
Если данные, которые вы храните в ListDictionary, всегда являются объектами (классами), а не типами значений, то это, вероятно, будет быстрее, чем Dictionary
В целом, однако, Я хотел бы отметить, что разница в производительности между этими двумя, вероятно, будет наименьшей из ваших проблем с производительностью в целом. Подобные мелочи - это последнее, о чем следует беспокоиться, когда дело касается оптимизации производительности. Более крупномасштабные вещи, такие как межпроцессные вызовы, взаимодействие с базой данных и веб-сервисами и т. Д.
Простая проверка класса MSDN-ListDictionary покажет
Это простая реализация IDictionary с использованием односвязного список. Он меньше и быстрее, чем Hashtable, если количество элементов 10 или меньше. Это не следует использовать, если производительность важна для больших количество элементов.