Feedback on my python framework I'm building.
http://giotto.readthedocs.org/en/latest/tutorial.html Can someone give me some feedback on what they think of this framework? I came up with the idea of this framework a few months ago. I gave a talk at a local python user group regarding these ideas, but no one seemed to think I was onto anything special or useful. 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. Does anyone have any throughts or feedback? -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback on my python framework I'm building.
On Saturday, October 13, 2012 10:13:22 AM UTC-4, Chris Angelico wrote: > On Sat, Oct 13, 2012 at 3:49 PM, 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) -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback on my python framework I'm building.
On Saturday, October 13, 2012 12:48:23 PM UTC-4, Chris Angelico wrote: > 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: Could you please spent 10 minutes to read through the tutorial? The 'tee' unix utility and ctypes describes the way giotto goes about it business very well. Traditional web frameworks (such as django and rails) are too much of a 'magic the gathering' for my taste, which is why I'm writing giotto. I'm really not looking for general "why I hate frameworks" criticism. I'm looking for specific criticism of the framework that I am writing. > 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. Not all api's get it right on the first shot. I'm more interested in getting it right, rather than patching together a bunch of random 'fixes' ala PHP. > 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 You just described what Giotto is trying to do, since Giotto doesn't touch the model at all. > 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. Exactly. When you 'break out of the framework' you pile on technical debt. I want to force developers to not do that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Feedback on my python framework I'm building.
On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote: > > Nice theory, but this is the bit that I fundamentally disagree with. > Forcing programmers to work in one particular style is usually not the > job of the language/framework/library. That should be up to the > programmer, or at least the local style guide. Have you ever read the zen of python? "Theres only one way to do it" is a core motto of the python language. In my opinion, this is the most important aspect of python and is what makes python so much better than PHP and perl and all the other "do it however you want, the more convoluted and obfuscated the better!" languages. > I do like your plan of > having identical interfaces to the same functionality (your example of > web-based and command-line is particularly appealing to my personal > tastes), but the same can usually be achieved with a well-built > library. In fact, all you need to do is have your model as a simple > Python module, and then the view and controller call on its functions. > > What does your framework offer over a basic system like that? This "well built library" you mention basically describes my framework. You write a model method/function that takes data and then returns data. All giotto does is extract that data from the controller, pass it on to the model, then take the output of the model and pass it in to the view. You write the view, you write the model. Giotto provides the API for making al this happen. Giotto doesn't care if your model calls Postgres or Mysql or Redis or RabbitMQ, thats not of any concern to the framework. The advantage of this is that the framework can 'mock' out the model layer very easily. For instance, your front end designers can work on the HTML without needing to run postgres, and the backend developers can work on the backend through the command line. -- http://mail.python.org/mailman/listinfo/python-list
How to get a package pip installable?
I made a python package that I wrote. I want to be able to install it via `pip install`. I wrote a setup.py file, and it works when I do `python setup.py develop|install|register`. The package even shows up on pipy (see it here: http://pypi.python.org/pypi/django-easydump/), but when I try to install it via pip: (test)chris@amnesia:~$ pip install easydump Downloading/unpacking easydump Could not find any downloads that satisfy the requirement easydump No distributions at all found for easydump Storing complete log in /Users/chris/.pip/pip.log (test)chris@amnesia:~$ pip install django-easydump Downloading/unpacking django-easydump Could not find any downloads that satisfy the requirement django-easydump No distributions at all found for django-easydump Storing complete log in /Users/chris/.pip/pip.log (text)chris@amnesia:~$ What am I missing? At first I thought I just needed to wait a few hours for the files to propigate across all mirrors, but its been a few days and it still doesn't work... -- http://mail.python.org/mailman/listinfo/python-list
Re: Deep merge two dicts?
On Thursday, April 12, 2012 5:54:47 PM UTC-4, Kiuhnm wrote:
> On 4/12/2012 19:59, John Nagle wrote:
> > On 4/12/2012 10:41 AM, Roy Smith wrote:
> >> Is there a simple way to deep merge two dicts? I'm looking for Perl's
> >> Hash::Merge (http://search.cpan.org/~dmuey/Hash-Merge-0.12/Merge.pm)
> >> in Python.
> >
> > def dmerge(a, b) :
> >for k in a :
> > v = a[k]
> > if isinstance(v, dict) and k in b:
> > dmerge(v, b[k])
> >a.update(b)
>
> There are a few problems with that code:
> 1) you don't make sure that b[k] is a dict so
> a={'a':{'b':1}}; b={'a':1}
> make it crash.
> 2) the last update overwrites nested updates, but this could be the
> intended behavior.
> For instance, with the 'a' and 'b' above, the result would be
> {'a':1}
>
> Kiuhnm
I guess it's reasonable that if a user wants to merge two dicts, the two dicts
should have the same structure. This kind of thing I've used before to merge
two logging config dictionaries:
https://docs.djangoproject.com/en/dev/topics/logging/#an-example
--
http://mail.python.org/mailman/listinfo/python-list
