Feedback on my python framework I'm building.

nbvfour at gmail.com nbvfour at gmail.com
Sat Oct 13 11:57:47 EDT 2012


On Saturday, October 13, 2012 10:13:22 AM UTC-4, Chris Angelico wrote:
> On Sat, Oct 13, 2012 at 3:49 PM,  <nbvfour at gmail.com> wrote:
> 
> > Basically its a framework that forces the developer(s) to strictly separate the model from the view and controller. You can 'hook up' multiple controllers to a project. The model layer can be completely mocked out so front end designers don't have to bother setting up Postgres/rabbitmq/whatever.
> 
> 
> 
> I don't like frameworks that force too much. Actually, I guess that
> 
> means I don't like frameworks at all, I like toolsets. Let the
> 
> programmer decide what he wants to do.
> 
> 
> 
> That said, though, there are times when a good framework can do 90% of
> 
> your work for you. The trouble comes when you want to do something the
> 
> author didn't think of - you might well end up either fighting against
> 
> the system, or modifying the framework to suit your task (and that
> 
> works only if you created it yourself). Thin frameworks are usually
> 
> immune to this, but on the flip side, they're less likely to be doing
> 
> most of your work for you.
> 
> 
> 
> It's really easy to demo something and show how awesome it is. How
> 
> easily can it be turned to a task it was never built for?
> 
> 
> 
> ChrisA

Do you have an example of a task that giotto can't handle that other frameworks can? One of my goals is to have this framework "turing complete" in the sense that everything that other frameworks can do, giotto should be able to do. I think my controller -> input_middleware -> model -> cache -> view -> output_middleware pattern pretty much allows for anything. Throughout the development process, I've radically changed the API many times when it was discovered that a certain task would be very hard (for instance authentication)



More information about the Python-list mailing list