DjangoBB LoFi version

Полная версия: Существую-ли генераторы(фабрики) функций?

Начало » Python для экспертов » Существую-ли генераторы(фабрики) функций?

1 2

Rom4eg196

Апрель 21, 2013 22:27:08

Дано: класс с десятком полей.
Необходимо: с помощью встроенного декоратора @property преобразовать каждое поле в свойство т.е.

class Static:
    def __init__(self, **kwargs)
        if 'today' in kwargs:
            self.today = kwargs['today']
        else:
            self.today = datetime.date.today()
        #поля в таком-же стиле т.е. разная статика
    @property
    def today(self):
        return self.today
    @today.setter
    def today(self,value):
        self.today = value
    @today.deleter
    def today(self):
        del self.today

и так с каждым полем. В результате очень много дублирующегося кода.

Суть вопроса: существует - ли более красивое/питоновское(Пайтоновское) решение или все это оформить в отдельном файле как есть?

Возможно, существуют “Генераторы(фабрики) функций(методов)” или декораторы, или неизвестное мне решение?

FishHook

Апрель 22, 2013 04:37:31

Сделать, наверное, можно, заюзав метапрограммирование.
Вопрос в том, зачем вам эти свойства.
Ведь в этом виде

@property
    def today(self):
        return self.today
    @today.setter
    def today(self,value):
        self.today = value
    @today.deleter
    def today(self):
        del self.today

обращение к свойству, ничем не отличается от обращения напрямую к полю. То есть без дополнительного кода в свойствах, который изменяет поведение при чтении/записи/удалении, применение свойств не дает никакого преимущества.
Но если мы добавим кода в свойства, то откуда же этот код возьмет “Генератор(фабрика) функций(методов)”?

Rom4eg196

Апрель 22, 2013 10:23:47

FishHook
обращение к свойству, ничем не отличается от обращения напрямую к полю.

Знаю, можно и напрямую изменить поле, но тогда теряется парадигма ооп. Свойства нужны для реализации инкапсуляции.

FishHook
Но если мы добавим кода в свойства, то откуда же этот код возьмет “Генератор(фабрика) функций(методов)”?

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

appetito

Апрель 22, 2013 13:17:41

Rom4eg196
но тогда теряется парадигма ооп

а так теряется здравый смысл

Rom4eg196

Апрель 22, 2013 14:31:56

Всем спасибо за ответы, решение найдено. Вопрос решен.

вот такое

props={}
def myProp(fn):
    props[fn.__name__]=fn
class test():
    def __init__(self):
        self.x=5
    def __getattribute__(self, name):
        if name in props.keys():
            return props[name](self)
        return object.__getattribute__(self, name)
    def __delattribute__(self, name):
        if name in props.keys():
            del props[name]
            return
        object.__delattribute__(self, name)
    def __setattr__(self, name, value):
        if name in props.keys():
            return props[name](self, value)
        return object.__setattr__(self, name, value)
    @myProp
    def myfunc(self, value=None):
        if value:
            self.x=value*2
        return self.x-2
x= test()
print(x.myfunc)
x.myfunc=6
print(x.myfunc)

Soteric

Апрель 22, 2013 15:42:16

Поддерживаю appetito. Если свойство не делает ничего, кроме как возвращает и изменяет значение, то его можно заменить обращением к полю напрямую. Проблема появляется, когда вы все-таки хотите добавить некоторую логику в свойство, а весь клиентский код уже написан так, что обращается напрямую к полю. Его приходится переписывать. В случае с питоном для клиента прозрачно, обращается он к свойству или полю, вызов в любом случае будет “x.myfunc”. Когда понадобится свойство, то вы просто сделаете поле закрытым, а на его место подставите вызов свойства. Клиентский код ничего не заметит, а вы сохраните инкапсуляцию.

FishHook

Апрель 22, 2013 16:16:59

Rom4eg196
Знаю, можно и напрямую изменить поле, но тогда теряется парадигма ооп. Свойства нужны для реализации инкапсуляции.

Вы не замечали, что ООП в питоне и ООП в Джаве это несколько разные вещи?
Обращение к полям нарушает концепцию ООП в отдельных взятых мейнстримовых языках, а в питоне Ваше желание сделать ООП ради ООПа нарушает базовый постулат питона “Простое лучше сложного, явное лучше неявного”

Lexander

Апрель 22, 2013 17:56:51

FishHook
+1
Добавлю из недаво сказанного:

Guido van Rossum
Don't write Java (or C++, or Javascript, …) in Python

Rom4eg196

Апрель 23, 2013 01:11:14

Ребят, вы правда считаете, что код представленный выше аля “Решение вопроса” нарушает Дзен Питона или концепцию ООП?

Я старался сохранить баланс между постулатами Питона и ООП, разве получилось плохо?
Во всем важен баланс, слепое следование одному, конкретному постулату(парадигме и т.д.) в результате приведет к говнокоду который не достоин существования.

к Soteric:
Полностью согласен с Вами, сам придерживаюсь правила “Первое и основное выполнение поставленной задачи”, а рефакторинг и красота после. Вопрос задавался на этапе рефакторинга, изначально задача была выполнена максимально просто и быстро, скрипт работает и работает стабильно. Но разобратся в коде очень сложно, поэтому начал рефакторить код и приводить к адекватному виду и читаемости.

Soteric

Апрель 23, 2013 06:36:57

Я к тому, что если свойство ничего не делает, то его можно не создавать. Если делает, то его все равно придется написать. Поэтому ваша конструкция ничего не дает.