Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #31184 > unrolled thread
| Started by | nbvfour@gmail.com |
|---|---|
| First post | 2012-10-12 21:49 -0700 |
| Last post | 2012-10-13 10:44 -0400 |
| Articles | 4 on this page of 24 — 10 participants |
Back to article view | Back to comp.lang.python
Feedback on my python framework I'm building. nbvfour@gmail.com - 2012-10-12 21:49 -0700
Re: Feedback on my python framework I'm building. Etienne Robillard <animelovin@gmail.com> - 2012-10-13 04:18 -0400
Re: Feedback on my python framework I'm building. Chris Angelico <rosuav@gmail.com> - 2012-10-14 01:12 +1100
Re: Feedback on my python framework I'm building. nbvfour@gmail.com - 2012-10-13 08:57 -0700
Re: Feedback on my python framework I'm building. Etienne Robillard <animelovin@gmail.com> - 2012-10-13 12:10 -0400
Re: Feedback on my python framework I'm building. Chris Angelico <rosuav@gmail.com> - 2012-10-14 03:48 +1100
Re: Feedback on my python framework I'm building. nbvfour@gmail.com - 2012-10-13 11:18 -0700
Re: Feedback on my python framework I'm building. Chris Angelico <rosuav@gmail.com> - 2012-10-14 05:33 +1100
Re: Feedback on my python framework I'm building. nbvfour@gmail.com - 2012-10-13 15:24 -0700
Re: Feedback on my python framework I'm building. Chris Angelico <rosuav@gmail.com> - 2012-10-14 10:06 +1100
Re: Feedback on my python framework I'm building. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-14 02:25 +0000
Re: one obvious parser (was "Feedback on my python framework I'm building.") Tim Chase <python.list@tim.thechases.com> - 2012-10-13 21:53 -0500
Re: Feedback on my python framework I'm building. MRAB <python@mrabarnett.plus.com> - 2012-10-14 03:58 +0100
Re: Feedback on my python framework I'm building. nbvfour@gmail.com - 2012-10-13 15:24 -0700
Re: Feedback on my python framework I'm building. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-14 03:37 +0000
Re: Feedback on my python framework I'm building. Chris Angelico <rosuav@gmail.com> - 2012-10-14 15:20 +1100
Re: Feedback on my python framework I'm building. Roy Smith <roy@panix.com> - 2012-10-14 08:48 -0400
Re: Feedback on my python framework I'm building. Dave Angel <d@davea.name> - 2012-10-14 18:38 -0400
Re: Feedback on my python framework I'm building. MRAB <python@mrabarnett.plus.com> - 2012-10-15 00:40 +0100
Re: Feedback on my python framework I'm building. Roel Schroeven <roel@roelschroeven.net> - 2012-10-15 19:29 +0200
Re: Feedback on my python framework I'm building. nbvfour@gmail.com - 2012-10-13 11:18 -0700
Re: Feedback on my python framework I'm building. Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2012-10-14 01:43 +0100
Re: Feedback on my python framework I'm building. nbvfour@gmail.com - 2012-10-13 08:57 -0700
Re: Feedback on my python framework I'm building. Etienne Robillard <animelovin@gmail.com> - 2012-10-13 10:44 -0400
Page 2 of 2 — ← Prev page 1 [2]
| From | nbvfour@gmail.com |
|---|---|
| Date | 2012-10-13 11:18 -0700 |
| Message-ID | <mailman.2130.1350152329.27098.python-list@python.org> |
| In reply to | #31204 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Oscar Benjamin <oscar.j.benjamin@gmail.com> |
|---|---|
| Date | 2012-10-14 01:43 +0100 |
| Message-ID | <mailman.2158.1350175435.27098.python-list@python.org> |
| In reply to | #31201 |
On 13 October 2012 17:48, Chris Angelico <rosuav@gmail.com> wrote:
>
> 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.
Without further ado I announce the release of my new library that
simultaneously does everything and nothing. It can be installed with:
pip install ''
That's right: the library's name is the empty string (as it's source
and documentation). Don't be fooled by the error message from pip: the
library was correctly installed before you ran the command!
Other libraries have failed by imposing restrictions on usage in an
attempt to better serve a mere finite number of use cases. This
library is *equally optimal* for an uncountably infinite number of
purposes and comes with the strong guarantee that it will never
decrease your productivity in any situation whatsoever!
Oscar
P.S. I also have not taken 10 minutes to read the documentation for
giotto as I get the impression that is not relevant to any of my own
use cases.
[toc] | [prev] | [next] | [standalone]
| From | nbvfour@gmail.com |
|---|---|
| Date | 2012-10-13 08:57 -0700 |
| Message-ID | <mailman.2120.1350143875.27098.python-list@python.org> |
| In reply to | #31197 |
On Saturday, October 13, 2012 10:13:22 AM UTC-4, Chris Angelico wrote: > On Sat, Oct 13, 2012 at 3:49 PM, <nbvfour@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)
[toc] | [prev] | [next] | [standalone]
| From | Etienne Robillard <animelovin@gmail.com> |
|---|---|
| Date | 2012-10-13 10:44 -0400 |
| Message-ID | <mailman.2117.1350139479.27098.python-list@python.org> |
| In reply to | #31184 |
On Sun, 14 Oct 2012 01:12:30 +1100 Chris Angelico <rosuav@gmail.com> wrote: > On Sat, Oct 13, 2012 at 3:49 PM, <nbvfour@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? Perhaps we deserve such lame/mediocre web frameworks after all, as Imagination is for those who deserve the freedom to use it properly. > ChrisA > -- > http://mail.python.org/mailman/listinfo/python-list -- Etienne Robillard Green Tea Hackers Club Fine Software Carpentry For The Rest Of Us! http://gthc.org/ erob@gthcfoundation.org
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.python
csiph-web