On Sun, Oct 14, 2012 at 2:57 AM, <nbvf...@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 -- http://mail.python.org/mailman/listinfo/python-list
