Hi, Not sure if anyone is reading that list, but posting that here can't be a bad idea either. There is now an experimental development branch for module support in Flask: http://github.com/mitsuhiko/flask/tree/module-support The idea is that you can have multiple modules and combine them into a larger application. To see how that works, check out the tests and/or build the documentation of that branch with Sphinx. Regards, Armin
> Not sure if anyone is reading that list Every. single. message. :) I think the modules work is looking good. In reading the docs, another idea occurred to me that I'm going to throw out. @app.route('/meh') def meh(): pass seems like the rule could be optional when you're fine with the defaults. It would become: @app.route() def meh(): pass Seems like it removes some redundancy. Thoughts? Chris -- Chris Grindstaff | http://gstaff.org
> seems like the rule could be optional when you're fine with the defaults. > It would become: > @app.route() > def meh(): > pass > Seems like it removes some redundancy. Funny enough I sent this before I saw you comment to sebest's template filter where he did something very similar. I see you didn't like the idea there ("too much magic" I think?), so I'm guessing you won't like this one either since it's nearly identical. Unless I've misread you comment. I still think this form removes redundancy. -Chris -- Chris Grindstaff | http://gstaff.org
Hi, On 2010-04-25 4:33 AM, Chris Grindstaff wrote: > Funny enough I sent this before I saw you comment to sebest's template > filter where he did something very similar. I see you didn't like the idea > there ("too much magic" I think?), so I'm guessing you won't like this one > either since it's nearly identical. There is a big difference. In your case it's still "@route()" and not "@route" which is a huge difference. I like the idea of optional arguments for URLs, the question is how far that should go (function argument introspection) which is probably possible and not too magical, but because of the inability to annotate types in common Python versions not that interesting. Regards, Armin
I'd just like to say hi (this is my first time posting to the list), and
give my two cents about Chris Grindstaff's suggestion.
I really like the option URL parameters, and I think it should definitely
include the ability to introspect the function arguments and add those as
separate URL paths, eg:
@app.route()
def user(username):
pass
would translate to:
@app.route('/user/<username>')
def user(username=None):
pass
And
@app.route()
def user(users, username, usertype):
pass
would translate to:
@app.route('/users/username/<usertype>')
def users(username, usertype=None):
pass
In this way, the introspection and automatic url routing would be limited to
setting the last arg as a variable, and the rest as the preceding URL path.
It would also limit the amount of 'guesswork' that the framework does, and
is pretty simple to learn / figure out by looking at code samples.
Again, just my two cents.
-Randall
On Sun, Apr 25, 2010 at 5:00 AM, Armin Ronacher <armin.ronacher@active-4.com
> wrote:
> Hi,
>
> On 2010-04-25 4:33 AM, Chris Grindstaff wrote:
> > Funny enough I sent this before I saw you comment to sebest's template
> > filter where he did something very similar. I see you didn't like the
> idea
> > there ("too much magic" I think?), so I'm guessing you won't like this
> one
> > either since it's nearly identical.
> There is a big difference. In your case it's still "@route()" and not
> "@route" which is a huge difference. I like the idea of optional
> arguments for URLs, the question is how far that should go (function
> argument introspection) which is probably possible and not too magical,
> but because of the inability to annotate types in common Python versions
> not that interesting.
>
>
> Regards,
> Armin
>
Randall Degges
What's the development plan for module-support ? Is it going into 0.3 ? On 25 April 2010 18:50, Randall Degges <rdegges@gmail.com> wrote: > I'd just like to say hi (this is my first time posting to the list), and > give my two cents about Chris Grindstaff's suggestion. > I really like the option URL parameters, and I think it should definitely > include the ability to introspect the function arguments and add those as > separate URL paths, eg: > @app.route() > def user(username): > pass > would translate to: > @app.route('/user/<username>') > def user(username=None): > pass > And > > @app.route() > def user(users, username, usertype): > pass > would translate to: > @app.route('/users/username/<usertype>') > def users(username, usertype=None): > pass > In this way, the introspection and automatic url routing would be limited to > setting the last arg as a variable, and the rest as the preceding URL path. > It would also limit the amount of 'guesswork' that the framework does, and > is pretty simple to learn / figure out by looking at code samples. > Again, just my two cents. > -Randall > On Sun, Apr 25, 2010 at 5:00 AM, Armin Ronacher > <armin.ronacher@active-4.com> wrote: >> >> Hi, >> >> On 2010-04-25 4:33 AM, Chris Grindstaff wrote: >> > Funny enough I sent this before I saw you comment to sebest's template >> > filter where he did something very similar. I see you didn't like the >> > idea >> > there ("too much magic" I think?), so I'm guessing you won't like this >> > one >> > either since it's nearly identical. >> There is a big difference. In your case it's still "@route()" and not >> "@route" which is a huge difference. I like the idea of optional >> arguments for URLs, the question is how far that should go (function >> argument introspection) which is probably possible and not too magical, >> but because of the inability to annotate types in common Python versions >> not that interesting. >> >> >> Regards, >> Armin > > Randall Degges -- Dan Jacob Skype: danjac40 Mobile: (++44) (0)777 290 8352
Hi,
On 4/29/10 3:04 PM, Dan Jacob wrote:
> What's the development plan for module-support ? Is it going into 0.3 ?
I'm aiming for 0.2
Regards,
Armin
Cool thanks! On Apr 24, 2010, at 2:19 PM, Armin Ronacher <armin.ronacher@active-4.com> wrote: > Hi, > > Not sure if anyone is reading that list, but posting that here can't > be > a bad idea either. There is now an experimental development branch > for > module support in Flask: > > http://github.com/mitsuhiko/flask/tree/module-support > > The idea is that you can have multiple modules and combine them into a > larger application. To see how that works, check out the tests and/or > build the documentation of that branch with Sphinx. > > > Regards, > Armin