Python-сообщество

>> REST - лучший. Но только тема несколько выходит за рамки топика. Поэтому с ходу настоятельно советовать поостерегся.

Это библиотека или технология. Если не сложно, дай ссылку, с которой лучше начать знакомство.
И почему на Pyro? Я примеры посмотрел - вроде то, что надо.

Да и от этой проблемы избавлена:

>> Проблема для RPyC очень простая: можно не заметить, что твой код уже перелез на сервер и потому жутко тормозит.

Кстати, попытался сделать вот такой workaround (сервер):

from SimpleXMLRPCServer import SimpleXMLRPCServer
from SimpleXMLRPCServer import SimpleXMLRPCRequestHandler

# Restrict to a particular path.
class RequestHandler(SimpleXMLRPCRequestHandler):
    rpc_paths = ('/RPC2',)

# Create server
server = SimpleXMLRPCServer(("localhost", 8000),
                            requestHandler=RequestHandler)
server.register_introspection_functions()

class MyClass:
    def __init__(self, a):
        self.a = a
    def say(self):
        return a

cl = MyClass(100)

def return_my_value():
    return cl.say()
    
server.register_function(return_my_value, 'r_v')
        
# Run the server's main loop
server.serve_forever()

demas

    def __init__(self, a):
        self.a = a
    def say(self):
        return a

xmlrpclib.Fault: <Fault 1: “<type ‘exceptions.NameError’>:global name ‘a’ is not defined”>

Такое ощущение, что на сервере вообще нельзя держать долгоживущих объектов, а все необходимое для ответа на запрос надо создавать заново для каждого запроса….
Как же тогда с кешированием быть.

Ааа….. спасибо.
Да, действительно.
Спасибо.

demas
REST - технология. О ней довольно много говорят, но чтобы ссылку дать…
Википедия подойдет?. Дальше самому смотреть нужно. Бикинг довольно недавно что-то писал.
Особенность в том, что REST - это очень просто. Все в HTTP - не путать с HTML (который лишь один из диалектов - content-type для http).
Имеешь URI (он же URL). Делаешь правильный запрос. Получаешь адекватный ответ.

Основные принципы:
- все строится на ресурсах
- у каждого ресурса - свой уникальный URI
- форматов представления - множество. Задаются через content-type
- у каждого ресурса есть несколько применимых к нему операций: put, get, delete и т.д.

Примерно так. Это просто еще одна хорошая парадигма. Неочевидная (как неочевидны объектно-ориентированное, функциональное, аспектное, мета - и прочие отличные техники).

Pyro, как и RPyC, не избавлен от следующей проблемы: все что пиклится - проходит. В результате можешь обнаружить, что через сетку лезет уж вовсе непотребное. У нас поймали что-то вроде SQLAlchemy enity, только в нашей ORM (смотрую на новый SQLAlchemy и подумываю - а теперь-то можно попробовать написать правильный адаптер для нашего нереляционного источника. Хоть Байер на PyCon и всячески открещивался от подобных задумок). Объяснил, что так совсем нельзя. Категорически отверг идеи “приспособить как-нибудь”. В результате пересмотрели код и сделали правильно.

Pyro и RPyC для меня - одного поля ягоды. RPyC немножко более Pythonic и потому предпочтительней. Pyro неоправданно тяжеловесен и задумывался как аналог JMI. Со всеми вытекающими.

Кстати, на PyCon была интересная лекция на тему: “Почему некоторые шаблоны проектирования не применяются в Питоне”.
Брали очевидные: visitor, factory… здесь
Было очень здорово (слайды не отражают сказанного, хотя обрисовывают задачку).
Потом часто звучало:

from __future__ import java_style
Traceback (SyntaxError: future feature java_style is not defined (<interactive input>, line 1)

Андрей Светлов
demas
REST - технология. О ней довольно много говорят, но чтобы ссылку дать…