Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

In Python, is the proper name for the PersonXXX class below PersonProxy, PersonInterface, etc?

import rest

class  PersonXXX(object):

    def __init__(self,db_url):
        self.resource = rest.Resource(db_url)

    def create(self,person):

    def get(self):

    def update(self):

    def delete(self):

class Person(object):

    def __init__(self,name, age):
        self.name = name
        self.age = age

    def data(self):
        return dict(name=self.name,age=self.age)

migration rejected from stackoverflow.com Sep 4 '14 at 2:39

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by gnat, Bart van Ingen Schenau, MichaelT, Dan Pichelman, GlenH7 Sep 4 '14 at 2:39

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

2 Answers 2

It is a Handler, right? It is the thing that mediates the interpretation of Person objects for use by the REST interface.

It can be called any one of a number of more specialized things. But that is its generic name, if you want to look at it from the Person-object's point of view, rather than from the REST system's.

It is not a Proxy because it does not pretend to be a Person object, it is an Interface but on REST not on Person, and it fails to inherit this formally, so it is only kind of a 'duck' Interface. It does not manage the created Person objects, nor does it collect them, and it is not part of one. So that kills most of the answers floated before.

Presumably it will be consumed by something that coordinates when to send stuff to the external system, or it will be used as an intermediary by code that is focused on the REST system and not on Person objects (I am synchronizing various things, and this one is a Person).


Django calls this a Manager. Your PersonXXX class exists at Person.objects, while Person itself encapsulates a single person record.


Django's ORM is a joy to work with, and highly respected. Coming from PHP/spaghetti, it was the first piece of code I ever considered "beautiful."

Since you're designing a persistence framework, I highly recommend you read about/play with it.

Thank you for that pointer. One of the reasons I liked the single-class approach is it allowed me to subclass models and do stuff like: def get(id): #code-goes-here return self(results) and I didn't want to give up the simplicity of return self(results). But, in other places, such as the query module, I pass in the "model" classes so the results could be initialized to the proper class. Evidently this is what Django is doing too. I finally bit the bullet and switched back to the two class approach where a proxy does the get instead of a subclass and am passing the model class to proxy. –  espeed Jun 29 '11 at 20:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.