Although I don't use the email feature, I agree with Matteo. A line must be drawn somewhere, and for web.py the philosophy seems to be "add a simple layer above the most common python features for building a quick and easy web application."
Sure, we could pull out email, db, sessions, forms, etc. And of course (like in my case) some people need more than what the web.py wrappers provide. But, I think these wrappers meet a large percentage of use cases, and protect developers from having to dig deep into python to do something simple like hit mysql or send an email. Web.py loses it's luster as a 'quick start' development framework if we take out too much stuff. All that being said, I do agree that we could modularize some wrappers and add plugins. For example I've got code that talks to sql server, oracle and sqlanywhere. These "extensions" should at the very least be in the web.py documentation as examples, or possibly even added as* *optional** modules. (since they require 3rd party libs and aren't common cases) NSC On Tue, May 21, 2013 at 4:35 PM, Matteo Landi <mat...@matteolandi.net>wrote: > On Tue, May 21, 2013 at 6:45 PM, Tae Sandoval Murgan <taeci...@gmail.com> > wrote: > > Maybe web.py should be considered as a "Python package" composed of > > several "Python modules" which objective is web development, like > > session.py, templetor.py, etc., more than a "web framework". If > > Python has a module to send emails, I don't see the need for a new > > one, unless that module doesn't fit with "the ideal way to write a web > > app". > > > > I like the idea of keeping in the framework only the necessary > modules, however I see a potential issue in _blindly_ following this > strategy. Let's take the email api as an example: it is just a tiny > wrapper around the Python api, nothing more, so why should it be kept > in the framework? In my opinion (please correct me if wrong), that > module is there (and hope will last) to create a common interface > handy to create pluggable extensions: do you want to create and share > an extension which at some point needs to send an email? Easy, use > ``web.sendmail`` and you are done. Without that common interface this > would not be possible. > > > Cheers, > > Matteo > > > -- > > You received this message because you are subscribed to the Google > Groups "web.py" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to webpy+unsubscr...@googlegroups.com. > > To post to this group, send email to webpy@googlegroups.com. > > Visit this group at http://groups.google.com/group/webpy?hl=en. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > -- > You received this message because you are subscribed to the Google Groups > "web.py" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to webpy+unsubscr...@googlegroups.com. > To post to this group, send email to webpy@googlegroups.com. > Visit this group at http://groups.google.com/group/webpy?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "web.py" group. To unsubscribe from this group and stop receiving emails from it, send an email to webpy+unsubscr...@googlegroups.com. To post to this group, send email to webpy@googlegroups.com. Visit this group at http://groups.google.com/group/webpy?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
