1) Не всё столь динамично в языке. Вот какие методы должны быть у типа для финкций? Не понятно. А зачем наследовать? Не понятно.
2) Это для классов. Что логично, можно сделать статический метод, не динамический, как обычные методы. Это концепция ООП.

>1) Раз всё в питоне - объекты

не всё

2) Наткнулся на интересную функцию - staticmethod. Чем статический метод отличается от функции?

Тем, что статический метод - это «метод класса». Обычный метод - «метод объекта».

Хочу сделать сложение функций))

Например так:

f+g(x) = f(x) + g(x)

Зачем надо не спрашивай) Может по другому можно?

Вот какие методы должны быть у типа для финкций?

dir (lambda x:x)

['__call__', '__class__', '__delattr__', '__dict__', '__doc__', '__get__', '__getattribute__', '__hash__', '__init__', '__module__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__', 'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name']

Таки не понятно тогда, что это, но похоже на методы и атрибуты

Не методы у функции, а методы у функции как типа.
У лямбды та же идея.
Складывать функции? Как?

f+g(x) = f(x) + g(x)

Это ты складываешь либо адрес функции, либо строковое представление(__repr__()) функции f с результатом выполнения функции g от x. Что ты курил написав далее «= -//-», я не знаю.

> не всё

разве?

foo = lambda x: x foo.__class__ наличествует, значит, класс.

> Это ты складываешь либо адрес функции, либо строковое представление(__repr__()) функции f с результатом выполнения функции g от x. Что ты курил написав далее «= -//-», я не знаю.

Нет, это просто типа определение суммы функций. Программирование тут не причем.

Ага, мне тоже так показалось, вот и написал

Вот вы путаете тип и экземпляр типа.

>>> a = lambda x: x
>>> dir(a)
['__call__', '__class__', '__closure__', '__code__', '__defaults__', ...
>>> dir(lambda)
SyntaxError: invalid syntax
>>> def a(x):
...     return x
>>> dir(a)
['__call__', '__class__', '__closure__', '__code__', '__defaults__', ...
>>> dir(function)
NameError: name 'function' is not defined
>>> dir(class)
SyntaxError: invalid syntax

Спасибо, я теперь тоже понял, почему dir (function) дает ошибку

> Вот вы путаете тип и экземпляр типа.

Хватит уже позориться, ты бы еще dir(for) нам показал.

dir(type(lambda x:x))

['__call__', '__class__', '__closure__', '__code__', '__defaults__', '__delattr__', '__dict__', '__doc__', '__format__', '__get__', '__getattribute__', '__globals__', '__hash__', '__init__', '__module__', '__name__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'func_closure', 'func_code', 'func_defaults', 'func_dict', 'func_doc', 'func_globals', 'func_name']

> Спасибо, я теперь тоже понял, почему dir (function) дает ошибку

Потому что тип называется не function.

>>>1) Раз всё в питоне - объекты

не всё

разве?

Лямбды с функциями-то ладно, Бог с ними, объекты. А управляющие конструкции? А циклы?

Тогда не понятно, почему type от функции дает function

> Лямбды с функциями-то ладно, Бог с ними, объекты. А управляющие конструкции? А циклы?

Да, да, мы помним про смолток.

> Тогда не понятно, почему type от функции дает function

Она не дает function, это ты все путаешь.

Вот тебе так лень залогиниться чтоль? Ты у меня давно в игноре и у меня нет никакого желания читать твои сообщения. Конечно, они оба являются типами, у них есть свойства. Что у лямбд, что у функций(фактически, одна вещь):

>>> a = lambda x: x
>>> dir(type(a))
['__call__', '__class__', '__closure__', '__code__', '__defaults__', ...
>>> def a(x):
...     return x
>>> dir(type(a))
['__call__', '__class__', '__closure__', '__code__', '__defaults__', ...

гы-гы :)

Не лисп же, по сему не объекты.

> Не лисп же, по сему не объекты.

Дурачок, в лиспе управляющие конструкцие - не являются объектами, в этом отношении он совершенно не отличается от пайтона.

Идиотинка, ты откуда взял мысль что в листе управляющие конструкции являются объектами?

> Конечно, они оба являются типами, у них есть свойства.

Конечно являются, а также являются классами.

Однако, повторюсь, для таких упоротых как ты, это не совсем объект. От него нельзя наследоваться.

Это совсем объект и совсем класс. Просто некоторые built-in классы позволяют наследоваться, а некоторые нет. Например, types.FunctionType не позволяет, а вот types.ListType - да.

> Идиотинка, ты откуда взял мысль что в листе управляющие конструкции являются объектами?

y: Лямбды с функциями-то ладно, Бог с ними, объекты. А управляющие конструкции? А циклы?

t: Не лисп же, по сему не объекты.

Из чего логично вытекает, что t считает, что в лиспе управляющие конструкции - объекты

>Это совсем объект и совсем класс.
Поищи на тему объектности классов/функций письма в рассылках пайтона. Там часто упоминался этот вопрос. Данные типы являются не совсем объектами, что не мешает им иметь локальное пространство имён, а точнее, методов и переменных.

Просто некоторые built-in классы позволяют наследоваться, а некоторые нет. Например, types.FunctionType не позволяет, а вот types.ListType - да.

Браво. Учитывая то что я выше это написал я могу сказать что ты способен обучаться.

>Из чего логично
Логику почини или обратись к специалисту. Из того что это не лисп, следует что автор не прав, а автор утверждал(предполагал/спрашивал) что управляющие структуры являются объектами. В лиспе макросы являются оперируемым объектом, с которым можно работать как хочешь, но поскольку пайтон это не лисп, то работать с его управляющими конструкциями так нельзя.
Усвоил урок?
Следующий сеанс - платно.

> В лиспе макросы являются оперируемым объектом, с которым можно работать как хочешь

напиши аналоги funcall и apply для макр

Данные типы являются не совсем объектами, что не мешает им иметь локальное пространство имён, а точнее, методов и переменных.

Ты точно блаженный, types.FunctionType - это класс, потому что можно создавать типы этого класса.

>>> def bar(x): return x*x
... 
>>> foo = types.FunctionType(bar.func_code, globals())
>>> foo(4)
16

> Из того что это не лисп, следует что автор не прав, а автор утверждал(предполагал/спрашивал) что управляющие структуры являются объектами.

Да, если ты такой тупой, что не заметил, что имелись ввиду настоящие объекты в смысле ООП, а не в бытовом, то я ничего уже не могу сделать. А в лиспе управляющие конструкции не являются объектами.

В лиспе макросы являются оперируемым объектом, с которым можно работать как хочешь

ты написал бред.

> создавать типы этого класса.

s/типы/объекты/

ты хотел сказать экземпляры?

а, все ))

>1) Раз всё в питоне - объекты, то и функции тоже. Объекты какого класса?

type (lambda x:x) дало <type 'function'> type (2) дало <type 'int'>

а вообще вот:

import types

types.FunctionType

<type 'function'>

> Хочу сделать сложение функций))

f+g(x) = f(x) + g(x)

Сделайте класс с переопределенными методами __call__() и __add__().

staticmethod нужно использовать как декоратор, по сути те же static-методы из c++

вот пример:

>>> class C:
...     @staticmethod
...     def f1(a,b):
...             pass
...     def f2(a,b):
...             pass
... 
>>> C.f1(1,2)
>>> C.f2(1.2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unbound method f2() must be called with C instance as first argument (got float instance instead)
>>>

Да, так и сделаю, спасибо. Собственно, я этот __call__ сразу заметил и что-то подобное хотел сделать

Что-то не работает __call__, ну да пофиг

Что-то не работает __call__, ну да пофиг

Что значит не работает?!

class my_function:
  def __add__(self, other):
    this = self
    class n(my_function):
      def __call__(self, x):
        return this(x)+other(x)
    return n()

class square(my_function):
  def __call__(self, x):
    return x*x

class cube(my_function):
  def __call__(self, x):
    return x*x*x

s = square()
c = cube()
print 's(2)=%d' % s(2)
print 'c(2)=%d' % c(2)
print '(c + s)(2)=%d' % (c + s)(2)

Ы?

class XFunction:
	def __init__(self, func):
		self._func = func

	def __add__(self, func):
		return XFunction(lambda *args, **kwargs: self._func(*args, **kwargs) + func(*args, **kwargs))

	def __call__(self, *args, **kwargs):
		return self._func(*args, **kwargs)

f = XFunction(lambda x: 2 * x)
g = XFunction(lambda x: x + 1)
f_g = f + g
print f_g(5)  # 2 * 5 + 5 + 1

Опередил :-/

Ну мой пример по-проще. )

> Ну мой пример по-проще. )

Троль на флейм разводит, а вы уже нерестится бисером начали )))

О, значит, я ступил.

Отмаза: Спать хотелось

Мне всё больше нравится твой код. Можно ещё вот так писать:

[code=python]@XFunction def square(x): return x * x [/code]

> f+g(x) = f(x) + g(x)

Нет, это просто типа определение суммы функций. Программирование тут не причем.

Как интересно. Похоже больше на определение композиции.

Правда что ль? Скорее частный случай.

Хочу сделать сложение функций))

Например так:

f+g(x) = f(x) + g(x)

в питоне нельзя передавать функции как параметры?

типа:

(define (sum f g)
  (lambda (x) (+ (f x) (g x))))

((sum f g) x)

или

(define (sum f g x)
  (+ (f x) (g x)))

(sum f g x)

Ты не понял, читай тред. Собственно, мне уже подсказали