Hi,
Flask 0.7 will merge in the blueprint branch which brings some changes
to everybody and this will also affect extensions. While we're always
trying to avoid breaking backwards compatibility, we chose to do a
backwards incompatible release this time in order to not have to deal
with problems in the future.
Extensions that are using the "flask.Module" object should consider
upgrading to "flask.Blueprint" if available. Please keep in mind that
the template lookup changed. If you want to support older versions than
0.7 we urge you to perform an attribute check on the "flask" module to
switch between the implementations. We will provide a guide for that
soon, but I think it won't affect many people as modules were
notoriously underused.
Also the after-request behavior was changed in that "after_request" is
no longer guaranteed to be executed on exceptions. However the newly
introduced "teardown_request" is. So extensions that need to execute
stuff at the end of request for cleanup are urged to upgrade.
The following code example shows how this can be done:
if hasattr(app, 'teardown_request'):
app.teardown_request(end_of_request)
else:
app.after_request(end_of_request)
Keep in mind that the parameter passed to this function is different.
It's a response object for after_request and an error or None for
teardown_request, so just ignore it!
The expected release for 0.7 will be tomorrow or by Tuesday, depending
on if we finish docs in time. Modules are still supported in 0.7 but
will raise deprecation warnings, the after request behavior however is
final and cannot be opted out. We will however provide a snippet for
how to replicate the old behavior if this is necessary.
Regards,
Armin
al., 2011.eko ekaren 27a 01:26(e)an, Armin Ronacher(e)k idatzi zuen: > Hi, > > Flask 0.7 will merge in the blueprint branch which brings some changes > to everybody and this will also affect extensions. While we're always > trying to avoid breaking backwards compatibility, we chose to do a > backwards incompatible release this time in order to not have to deal > with problems in the future. What about adding adding version compatibility information for extensions[1]? It's quite disappointing choosing an extension for your Flask app and seeing it's broken, especially if it's an approved extension, which should mean it mets a minimum set of requirements[2]. By the way, what's the procedure for reporting broken extensions? [1] http://flask.pocoo.org/extensions/ [2] http://flask.pocoo.org/docs/extensiondev/#approved-extensions
Thanks for the heads up, Armin. Since I won't be doin any flask dev in the near future, if anyone is interested taking over flask principal and any other extensions I forgot writing, please let me know. Otherwise RIP :) On Jun 27, 2011 1:26 AM, "Armin Ronacher" <armin.ronacher@active-4.com> wrote: > Hi, > > Flask 0.7 will merge in the blueprint branch which brings some changes > to everybody and this will also affect extensions. While we're always > trying to avoid breaking backwards compatibility, we chose to do a > backwards incompatible release this time in order to not have to deal > with problems in the future. > > Extensions that are using the "flask.Module" object should consider > upgrading to "flask.Blueprint" if available. Please keep in mind that > the template lookup changed. If you want to support older versions than > 0.7 we urge you to perform an attribute check on the "flask" module to > switch between the implementations. We will provide a guide for that > soon, but I think it won't affect many people as modules were > notoriously underused. > > Also the after-request behavior was changed in that "after_request" is > no longer guaranteed to be executed on exceptions. However the newly > introduced "teardown_request" is. So extensions that need to execute > stuff at the end of request for cleanup are urged to upgrade. > > The following code example shows how this can be done: > > if hasattr(app, 'teardown_request'): > app.teardown_request(end_of_request) > else: > app.after_request(end_of_request) > > Keep in mind that the parameter passed to this function is different. > It's a response object for after_request and an error or None for > teardown_request, so just ignore it! > > The expected release for 0.7 will be tomorrow or by Tuesday, depending > on if we finish docs in time. Modules are still supported in 0.7 but > will raise deprecation warnings, the after request behavior however is > final and cannot be opted out. We will however provide a snippet for > how to replicate the old behavior if this is necessary. > > > Regards, > Armin
I'll take over flask-principal if it's ok moving it to github, definitely dont want that to be RIP :) On Mon, Jun 27, 2011 at 12:33 PM, Ali Afshar <aafshar@gmail.com> wrote: > Thanks for the heads up, Armin. Since I won't be doin any flask dev in the > near future, if anyone is interested taking over flask principal and any > other extensions I forgot writing, please let me know. Otherwise RIP :) > > On Jun 27, 2011 1:26 AM, "Armin Ronacher" <armin.ronacher@active-4.com> > wrote: >> Hi, >> >> Flask 0.7 will merge in the blueprint branch which brings some changes >> to everybody and this will also affect extensions. While we're always >> trying to avoid breaking backwards compatibility, we chose to do a >> backwards incompatible release this time in order to not have to deal >> with problems in the future. >> >> Extensions that are using the "flask.Module" object should consider >> upgrading to "flask.Blueprint" if available. Please keep in mind that >> the template lookup changed. If you want to support older versions than >> 0.7 we urge you to perform an attribute check on the "flask" module to >> switch between the implementations. We will provide a guide for that >> soon, but I think it won't affect many people as modules were >> notoriously underused. >> >> Also the after-request behavior was changed in that "after_request" is >> no longer guaranteed to be executed on exceptions. However the newly >> introduced "teardown_request" is. So extensions that need to execute >> stuff at the end of request for cleanup are urged to upgrade. >> >> The following code example shows how this can be done: >> >> if hasattr(app, 'teardown_request'): >> app.teardown_request(end_of_request) >> else: >> app.after_request(end_of_request) >> >> Keep in mind that the parameter passed to this function is different. >> It's a response object for after_request and an error or None for >> teardown_request, so just ignore it! >> >> The expected release for 0.7 will be tomorrow or by Tuesday, depending >> on if we finish docs in time. Modules are still supported in 0.7 but >> will raise deprecation warnings, the after request behavior however is >> final and cannot be opted out. We will however provide a snippet for >> how to replicate the old behavior if this is necessary. >> >> >> Regards, >> Armin >
Alfred, thanks! Now you own it, you can move it wherever you like! On Jun 27, 2011 1:36 PM, "Alfred Hall" <ahall@ahall.org> wrote: > I'll take over flask-principal if it's ok moving it to github, > definitely dont want that to be RIP :) > > On Mon, Jun 27, 2011 at 12:33 PM, Ali Afshar <aafshar@gmail.com> wrote: >> Thanks for the heads up, Armin. Since I won't be doin any flask dev in the >> near future, if anyone is interested taking over flask principal and any >> other extensions I forgot writing, please let me know. Otherwise RIP :) >> >> On Jun 27, 2011 1:26 AM, "Armin Ronacher" <armin.ronacher@active-4.com> >> wrote: >>> Hi, >>> >>> Flask 0.7 will merge in the blueprint branch which brings some changes >>> to everybody and this will also affect extensions. While we're always >>> trying to avoid breaking backwards compatibility, we chose to do a >>> backwards incompatible release this time in order to not have to deal >>> with problems in the future. >>> >>> Extensions that are using the "flask.Module" object should consider >>> upgrading to "flask.Blueprint" if available. Please keep in mind that >>> the template lookup changed. If you want to support older versions than >>> 0.7 we urge you to perform an attribute check on the "flask" module to >>> switch between the implementations. We will provide a guide for that >>> soon, but I think it won't affect many people as modules were >>> notoriously underused. >>> >>> Also the after-request behavior was changed in that "after_request" is >>> no longer guaranteed to be executed on exceptions. However the newly >>> introduced "teardown_request" is. So extensions that need to execute >>> stuff at the end of request for cleanup are urged to upgrade. >>> >>> The following code example shows how this can be done: >>> >>> if hasattr(app, 'teardown_request'): >>> app.teardown_request(end_of_request) >>> else: >>> app.after_request(end_of_request) >>> >>> Keep in mind that the parameter passed to this function is different. >>> It's a response object for after_request and an error or None for >>> teardown_request, so just ignore it! >>> >>> The expected release for 0.7 will be tomorrow or by Tuesday, depending >>> on if we finish docs in time. Modules are still supported in 0.7 but >>> will raise deprecation warnings, the after request behavior however is >>> final and cannot be opted out. We will however provide a snippet for >>> how to replicate the old behavior if this is necessary. >>> >>> >>> Regards, >>> Armin >>
On Mon, Jun 27, 2011 at 1:23 PM, Ali Afshar <aafshar@gmail.com> wrote:
> Now you own it, you can move it wherever you like!
Have you updated ownership on PyPI, too?
Thanks,
Ron
I will do immediately when the next release is ready. On 28 June 2011 00:49, Ron DuPlain <ron.duplain@gmail.com> wrote: > On Mon, Jun 27, 2011 at 1:23 PM, Ali Afshar <aafshar@gmail.com> wrote: >> Now you own it, you can move it wherever you like! > > Have you updated ownership on PyPI, too? > Thanks, > > Ron >