Feedback on my python framework I'm building.

[Chris Angelico]

On Sun, Oct 14, 2012 at 2:57 AM,  <nbvfour at gmail.com> wrote:
> 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.

No, I don't, because I haven't tried to use it. But allow me to give
two examples, one on each side of the argument.

The 'tee' utility is primarily for writing a pipe to disk AND to
further pipelining, for instance:

./grind | tee grind.log | egrep '(2012|tps|@)'

It'll show me, in real-time, the lines that are of interest to me, but
it also writes the whole log to disk. But tee can be used in a quite
different way:

echo "Hello, world!" | sudo tee /some/file/owned/by/root

Unix is full of utilities of this nature. They each do one thing and
do it well, so when someone wants to use them in unusual ways, the
tools perform as expected.

On the contrary, Magic: The Gathering Online is designed for one
purpose: human interaction. There are a number of bot accounts that
function as shopkeepers, but their owners have to either use GUI level
monitoring and automation facilities, or hack the existing client
brutally. These people are trying to use an application in a way that
it wasn't designed to do, and no matter how reasonable the goal is,
the program just isn't built with toolchaining in mind.

> 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)

This is, in my opinion, not a good thing. If you have to change your
API radically to support something you just thought of, then something
you still haven't thought of may require another radical API change.
That's not too bad if it's a personal system that you don't share with
anyone (though even then, you have to consider whether you'll be
spending more time fiddling with the framework than actually getting
stuff done), but is potentially disastrous in something you publish -
you can't afford to break everyone else's code, which means that
you'll be unable to support things you didn't think of.

The only way to support *absolutely everything* is to do nothing - to
be a framework so thin you're invisible. (That's not to say you're
useless; there are bridge modules that do exactly this - ctypes can
call on any library function from Python; it must therefore abstract
away nothing. But that's a very specific sort of case.) Anything else
must by nature make some things easier and some things harder.

The easiest way to avoid making things very much harder is to have a
way to ignore the framework - in the same way that most file
compression formats have a way to mark data as having not been
compressed (PKZip uses the term "Stored" rather than, eg, "Deflated").
 This is why I say it's likely not a good thing that your framework
*forces* the separation of model/view/controller. You make it
impossible to temporarily ignore the framework. I haven't tested your
specific case, but what I've seen happen in similar situations is a
ridiculous set of "pass-through" methods or parameters, getting sent
up the line and back down the line, carrying opaque information that
really ought to have been manipulated at a different level in the
chain. I can't show you demo code as I don't own copyright on it, but
the git repository at work has, shall we say, a certain amount of
TheDailyWTF-level code in it...

But please don't take this post as _entirely_ doom and gloom. For a
number of reasons, I do not want to start coding within your
framework; but I would recommend that you DO (continue to) do so.
You'll learn a lot about what you do and don't like, and that's a good
thing. You'll quite possibly end up building something that saves you
a heap of time, and that's also a good thing. And at very worst, it'll
be an exploration. All programmers benefit from writing more code :)
But so long as you keep it personal, you're free to change it around
completely every time you need to. Keep that flexibility and you won't
feel constrained.

ChrisA