> I don't like that Flask uses a global request object [3]. Przemyslaw, actually Pecan does use global objects too. BTW, what's wrong with global objects? They are thread-safe in both Pecan and Flask.
> IMHO documentation is better written, and described a lot of possibilities of > modification I disagree. Flask has rich documentation and more flexible, while Pecan forces us to use only its patterns and code organization. There are no possibilities to avoid this. I'm afraid with Pecan we will have to rewrite a lot of code. On Wed, Dec 3, 2014 at 2:21 PM, Kamil Sambor <ksam...@mirantis.com> wrote: > Additionaly to what Przemek wrote, also Pecan is released more often, IMHO > documentation is better written, and described a lot of possibilities of > modification, also as Lukasz wrote in previous thread that Pecan is used in > openstack. > > So I'm also for Pecan > > Best regards, > Kamil S. > > On Wed, Dec 3, 2014 at 12:45 PM, Przemyslaw Kaminski > <pkamin...@mirantis.com> wrote: >> >> The only useful paradigm to write in Flask is MethodView's for me [1] >> because decorators seem hard to refactor for large projects. Please look at >> adding URLs -- one has to additionally specify methods to match those from >> the MethodView -- this is code duplication and looks ugly. >> >> It seems though that Fask-RESTful [2] fixes this but then we're dependent >> on 2 projects. >> >> I don't like that Flask uses a global request object [3]. From Flask >> documentation >> >> "Basically you can completely ignore that this is the case unless you are >> doing something like unit testing. You will notice that code which depends >> on a request object will suddenly break because there is no request object. >> The solution is creating a request object yourself and binding it to the >> context." >> >> Yeah, let's make testing even harder... >> >> Pecan looks better in respect of RESTful services [4]. >> POST parameters are cleanly passed as arguments to the post method. It >> also provides custom JSON serialization hooks [5] so we can forget about >> explicit serialization in handlers. >> >> So from these 2 choices I'm for Pecan. >> >> [1] http://flask.pocoo.org/docs/0.10/views/#method-views-for-apis >> [2] https://flask-restful.readthedocs.org/en/0.3.0/ >> [3] http://flask.pocoo.org/docs/0.10/quickstart/#accessing-request-data >> [4] http://pecan.readthedocs.org/en/latest/rest.html >> [5] http://pecan.readthedocs.org/en/latest/jsonify.html >> >> >> P. >> >> >> On 12/03/2014 10:57 AM, Alexander Kislitsky wrote: >> >> We had used Flask in the fuel-stats. It was easy and pleasant and all >> project requirements was satisfied. And I saw difficulties and workarounds >> with Pecan, when Nick integrated it into Nailgun. >> So +1 for Flask. >> >> >> On Tue, Dec 2, 2014 at 11:00 PM, Nikolay Markov <nmar...@mirantis.com> >> wrote: >>> >>> Michael, we already solved all issues I described, and I just don't >>> want to solve them once again after moving to another framework. Also, >>> I think, nothing of these wishes contradicts with good API design. >>> >>> On Tue, Dec 2, 2014 at 10:49 PM, Michael Krotscheck >>> <krotsch...@gmail.com> wrote: >>> > This sounds more like you need to pay off technical debt and clean up >>> > your >>> > API. >>> > >>> > Michael >>> > >>> > On Tue Dec 02 2014 at 10:58:43 AM Nikolay Markov <nmar...@mirantis.com> >>> > wrote: >>> >> >>> >> Hello all, >>> >> >>> >> I actually tried to use Pecan and even created a couple of PoCs, but >>> >> there due to historical reasons of how our API is organized it will >>> >> take much more time to implement all workarounds we need to issues >>> >> Pecan doesn't solve out of the box, like working with non-RESTful >>> >> URLs, reverse URL lookup, returning custom body in 404 response, >>> >> wrapping errors to JSON automatically, etc. >>> >> >>> >> As far as I see, each OpenStack project implements its own workarounds >>> >> for these issues, but still it requires much less men and hours for us >>> >> to move to Flask-Restful instead of Pecan, because all these problems >>> >> are already solved there. >>> >> >>> >> BTW, I know a lot of pretty big projects using Flask (it's the second >>> >> most popular Web framework after Django in Python Web community), they >>> >> even have their own "hall of fame": >>> >> http://flask.pocoo.org/community/poweredby/ . >>> >> >>> >> On Tue, Dec 2, 2014 at 7:13 PM, Ryan Brown <rybr...@redhat.com> wrote: >>> >> > On 12/02/2014 09:55 AM, Igor Kalnitsky wrote: >>> >> >> Hi, Sebastian, >>> >> >> >>> >> >> Thank you for raising this topic again. >>> >> >> >>> >> >> [snip] >>> >> >> >>> >> >> Personally, I'd like to use Flask instead of Pecan, because first >>> >> >> one >>> >> >> is more production-ready tool and I like its design. But I believe >>> >> >> this should be resolved by voting. >>> >> >> >>> >> >> Thanks, >>> >> >> Igor >>> >> >> >>> >> >> On Tue, Dec 2, 2014 at 4:19 PM, Sebastian Kalinowski >>> >> >> <skalinow...@mirantis.com> wrote: >>> >> >>> Hi all, >>> >> >>> >>> >> >>> [snip explanation+history] >>> >> >>> >>> >> >>> Best, >>> >> >>> Sebastian >>> >> > >>> >> > Given that Pecan is used for other OpenStack projects and has plenty >>> >> > of >>> >> > builtin functionality (REST support, sessions, etc) I'd prefer it >>> >> > for a >>> >> > number of reasons. >>> >> > >>> >> > 1) Wouldn't have to pull in plugins for standard (in Pecan) things >>> >> > 2) Pecan is built for high traffic, where Flask is aimed at much >>> >> > smaller >>> >> > projects >>> >> > 3) Already used by other OpenStack projects, so common patterns can >>> >> > be >>> >> > reused as oslo libs >>> >> > >>> >> > Of course, the Flask community seems larger (though the average >>> >> > flask >>> >> > project seems pretty small). >>> >> > >>> >> > I'm not sure what determines "production readiness", but it seems to >>> >> > me >>> >> > like Fuel developers fall more in Pecan's target audience than in >>> >> > Flask's. >>> >> > >>> >> > My $0.02, >>> >> > Ryan >>> >> > >>> >> > -- >>> >> > Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. >>> >> > >>> >> > _______________________________________________ >>> >> > OpenStack-dev mailing list >>> >> > OpenStack-dev@lists.openstack.org >>> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >>> >> >>> >> >>> >> -- >>> >> Best regards, >>> >> Nick Markov >>> >> >>> >> _______________________________________________ >>> >> OpenStack-dev mailing list >>> >> OpenStack-dev@lists.openstack.org >>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> > >>> > _______________________________________________ >>> > OpenStack-dev mailing list >>> > OpenStack-dev@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Nick Markov >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
