web.py development plans

[Anand Chitipothu]

Hello everyone,

I've been wondering from long time about how to move forward about web.py development. Here is the summary of my thoughts.

Main Priorities:

* Python3 support

Python 3 is the future. We should make web.py ready for it.

* Better integration with third-party tools

web.py has not been very good at supporting integration with third-party tools and making it easier for other people to write some kind of extensions to web.py. I think this is very important for the adoption of web.py.

* Fixing the earlier design mistakes

There are some design mistakes that I would like to fix.

- The web.database module depends the request locals, which is a design mistake. I've started a new project to make the database module of web.py independent of other part of web.py. It is still work in progress. 

https://github.com/anandology/sqlpy

- We haven't got the form API is right. I've always extended form class, overwritten some important methods, etc, whenever I've tried to use it. This needs to be improved.

- Sessions. This another part of web.py that I'm not happy about. May be this  should have been an extension instead of core part of web.py. I'm not really sure what to do about this.

Please let me know your thoughts about this.

If there are any parts of web.py that you think need to be improved, or an API is not right, please let me know. 

Anand

[W. Martin Borgert]

Quoting "Anand Chitipothu" <anand...@gmail.com>:
> Main Priorities:
>
> * Python3 support

Would the upcoming 3.4 async API be useful for web.py?

> * Better integration with third-party tools

Yes, I tried to integrate web.py with dbus, which needs the
glib mainloop. The solution was multiprocessing - not nice.

> If there are any parts of web.py that you think need to be improved, or an
> API is not right, please let me know.

There is one very important point, I like to to see not improved:
Currently web.py is small, relatively easy to understand and one
can use it even on very small machines. Even without database and
omitting the template system. I like this very much - it is a huge
advantage over Django etc. (I'm using Django as well, but for
other types of applications.)

Cheers

[Anand Chitipothu]

If there are any parts of web.py that you think need to be improved, or an
API is not right, please let me know.

There is one very important point, I like to to see not improved:
Currently web.py is small, relatively easy to understand and one
can use it even on very small machines. Even without database and
omitting the template system. I like this very much - it is a huge
advantage over Django etc. (I'm using Django as well, but for
other types of applications.)

web.py will continue to be small, easy to understand and usable on very small machines, even if we make any improvements. What is that you are worries about?

Anand

[Tomas Schertel]

@Nickname:
I totally agree with you. Web.py have to keep things simple.

@Anand:
How can we help?
Give directions to everyone contribute.
Where and how can we edit documentation to renew it?

[Tae Sandoval Murgan]

On Thu, May 16, 2013 at 9:02 AM, Anand Chitipothu <anand...@gmail.com> wrote:
> Python 3 is the future. We should make web.py ready for it.

+1, but my concern is this:
https://en.wikipedia.org/wiki/Wsgi#WSGI_and_Python_3 Does that mean
that the CherryPy web server will be replaced?

> The web.database module depends the request locals, which is a design
> mistake. I've started a new project to make the database module of web.py
> independent of other part of web.py. It is still work in progress.

I like A LOT that idea because I love the UNIX philosophy, you know:
"write programs that do one thing and do it well. Write programs to
work together".

> We haven't got the form API is right. I've always extended form class,
> overwritten some important methods, etc, whenever I've tried to use it. This
> needs to be improved.

I want to work in the Form class! Give me this weekend to see if my
idea is possible. I'll send an email explaining which design I think
should be followed.

> Sessions. This another part of web.py that I'm not happy about. May be
> this should have been an extension instead of core part of web.py. I'm not
> really sure what to do about this.

+1. UNIX philosophy ;) And also, I found this email some time ago:
https://groups.google.com/forum/?fromgroups=#!searchin/webpy/$20why$20sessions$20are$20bad$20/webpy/KHCDcwLpDfA/KOIC0vB27OoJ
Having a session.py separated module seems the way to go (and also a
separated openid.py module?).

[W. Martin Borgert]

Quoting "Anand Chitipothu" <anand...@gmail.com>:
> web.py will continue to be small, easy to understand and usable on very
> small machines, even if we make any improvements. What is that you are
> worries about?

No worries at all! I just want to be sure, we all share the same
vision of web.py as a small and "readable" web framework.

[Tae Sandoval Murgan]

On Thu, May 16, 2013 at 11:35 AM, W. Martin Borgert <deb...@debian.org> wrote:
> No worries at all! I just want to be sure, we all share the same
> vision of web.py as a small and "readable" web framework.

That's a feature!

[J.Y Han]

good job!!

--

J.Y Han

http://han.im

Sent with Sparrow

--
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+un...@googlegroups.com.
To post to this group, send email to we...@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.
 
 

[Dragan Espenschied]

Anand, thanks for keeping webpy on the move!

> - We haven't got the form API is right. I've always extended form class,
> overwritten some important methods, etc, whenever I've tried to use it. This
> needs to be improved.

The form API's greatest shortcoming is, in my opinion, that it generates awful
looking forms. :) I wonder if it in general has uses outside of rapid
prototyping, because in other cases users would make their own forms.

I suggest splitting the creation and evaluation of forms into parts that could
easily be used independently. For example by making my own form in a template,
but having it checked by the form module. If evaluating forms would follow the
HTML5 form specifications, it would be really useful to support the
functionality in browsers that cannot do it natively. (And anyway you have to
evaluate the submitted forms on the server.) -- Maybe just by giving the form
elements in HTML some special names, with a _ in front or some other "namespace".

> - Sessions. This another part of web.py that I'm not happy about. May be this
> should have been an extension instead of core part of web.py. I'm not really
> sure what to do about this.

Sessions should transparently work in debug mode and have the option to set
expiration dates in the browser. Apart from these points, as a user I am very
happy with them.

I wonder if making them into a separate module and how far that would go, but I
think sessions are a core functionality of serverside web frameworks. Things
that can be done without sessions usually can be done completely on the client :)

> Please let me know your thoughts about this.
>
> If there are any parts of web.py that you think need to be improved, or an API
> is not right, please let me know.

I haven't been able to send UTF8 encoded emails with webpy. That would be great,
just to call the method and not having to care about the encoding.


Again, thanks and best greetings,
Dragan

[mat...@matteolandi.net]

First of all, thank you all for your hard work:  web.py is just amazing!

On Thursday, May 16, 2013 3:02:21 PM UTC+2, Anand wrote:

Hello everyone,

I've been wondering from long time about how to move forward about web.py development. Here is the summary of my thoughts.

Main Priorities:

* Python3 support

Python 3 is the future. We should make web.py ready for it.

 

* Better integration with third-party tools

web.py has not been very good at supporting integration with third-party tools and making it easier for other people to write some kind of extensions to web.py. I think this is very important for the adoption of web.py.

Rather than adding support for integrating with third-party tools, what this framework really lacks of is a central archive containing guides, tutorials, best practices of how to use web.py in production-like environments.  I mean, I had no issues in using web.py with celery, sqlalchemy, webassets or wtforms, even if the framework lacks of extensions support.

The site already offers a wiki and a cookbook with useful recipes but we definitely need to  keep them up to date with new technologies etc.
 

* Fixing the earlier design mistakes

There are some design mistakes that I would like to fix.

- The web.database module depends the request locals, which is a design mistake. I've started a new project to make the database module of web.py independent of other part of web.py. It is still work in progress. 

https://github.com/anandology/sqlpy

What is the purpose of the database module?  I think the reason it has been included in the framework is simply to enable users to create applications without linking external libraries or tools (one cannot think of a web-app without a database interface).  But, does the database module really want to take the place of other ORMs (e.g. SQLAlchemy)?

With that said, I see the design problem and I think it should be fixed.
 

- We haven't got the form API is right. I've always extended form class, overwritten some important methods, etc, whenever I've tried to use it. This needs to be improved.

- Sessions. This another part of web.py that I'm not happy about. May be this  should have been an extension instead of core part of web.py. I'm not really sure what to do about this.

Please let me know your thoughts about this.

If there are any parts of web.py that you think need to be improved, or an API is not right, please let me know. 

Let me think about that.  I will get back to the list as soon as I have collected some ideas.


Cheers,

Matteo
 

Anand

[W. Martin Borgert]

On 2013-05-19 14:07, Dragan Espenschied wrote:
> I haven't been able to send UTF8 encoded emails with webpy. That would be great,
> just to call the method and not having to care about the encoding.

I wonder, why web.py does have an e-mail API anyway. This is
sth. that could be separated. Python already has an e-mail API
and if there is the need for something more advanced, it could
be another framework, not web.py.

[Tae Sandoval Murgan]

On Sun, May 19, 2013 at 8:07 AM, Dragan Espenschied <d...@a-blast.org> wrote:
> I suggest splitting the creation and evaluation of forms into parts that could
> easily be used independently. For example by making my own form in a template,
> but having it checked by the form module. If evaluating forms would follow the
> HTML5 form specifications, it would be really useful to support the
> functionality in browsers that cannot do it natively. (And anyway you have to
> evaluate the submitted forms on the server.) -- Maybe just by giving the form
> elements in HTML some special names, with a _ in front or some other "namespace".

That's what I want to do! I have three free days off, so I'll try to
show something on Wednesday.

[Dragan Espenschied]

From my experience the great thing about webpy is that it includes all the
basics one might want from a web application, and is still super-simple.

Python has APIs for almost anything, so consequently webpy could be reduced to
its URL mapper probably. :) A web framework needs sessions, templates, database,
email, otherwise it is useless.

[Tomas Schertel]

I think too web.py should keep sessions in core.

@Anand, any news?

[Steven Brown]

I agree.  Think about when you sign up for a website, at the very least.  Usually that involves an email confirmation.  This is one of the most common things, so I think it should be included.

[W. Martin Borgert]

Quoting "Dragan Espenschied" <d...@a-blast.org>:
> Python has APIs for almost anything, so consequently webpy could be
> reduced to
> its URL mapper probably. :) A web framework needs sessions,
> templates, database,
> email, otherwise it is useless.

Maybe I don't understand the web.py email API well enough:
Why do I need it? If I like to send email, I can just use
Python.

"Django lets you write web apps in Django. TurboGears lets
you write web apps in TurboGears. Web.py lets you write web
apps in Python" (Adam Atlas on http://webpy.org/)

URL mapping, sessions, templates, database access is all web
related, and the functionality is not in core Python. e-mail
is not the web and Python already has an e-mail API. One can
use it with web apps, just like FTP, SCP or XMPP might be
relevant. But why have an e-mail API in web.py?

[Zhang Huangbin]

On Tuesday, May 21, 2013 10:42:01 PM UTC+8, Steven Brown wrote:

I agree.  Think about when you sign up for a website, at the very least.  Usually that involves an email confirmation.  This is one of the most common things, so I think it should be included.

+1 for keeping session in core.

-1 for keeping mail api in core.

Current mail API in webpy is almost the same as smtplib.

*) webpy mail api basic usage: http://webpy.org/cookbook/sendmail

*) smtplib: http://docs.python.org/2/library/smtplib.html#smtp-example

[Tomas Schertel]

Agreed with Zhang:

[Tae Sandoval Murgan]

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".

[Matteo Landi]

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

[Shannon Cruey]

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

[Zhang Huangbin]

On Wednesday, May 22, 2013 4:35:14 AM UTC+8, Matteo Landi wrote:

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.

Let's make it simpler here.

*) web.sendmail() is used to mail "internal server error" message to

specified email address(es) in web.py, do you need this feature?

[used in module debugerror.py, function emailerrors() if you don't want

to check source code.]

*) If you just use web.sendmail() to send plain email without attachment,

smtplib is as easy as web.sendmail(). But if you want to send attachment,

i bet you will wrap smtplib+email modules in your own function.

Personally, i let my web.py application mail me "internal server error"

message automatically when error occurs, on production server.

[code i use, if you're curious:

app.internalerror = web.emailerrors('postm...@domain.ltd', web.webapi._InternalError)

]

Keeping or removing web.sendmail() is not a big deal, but it's really handy.

I guess most users will vote for keeping it in core. :)

[Tomas Schertel]

Is pypy support planned?
uWSGI now works with pypy[1]. Maybe web.py could support it too.

[1] - http://uwsgi-docs.readthedocs.org/en/latest/PyPy.html

[Tomas Schertel]

Armin Ronacher, from Jinja2, wrote about his experience on making Jinja2 support both python 2 and python3.

[1] - http://lucumr.pocoo.org/2013/5/21/porting-to-python-3-redux/

[Zagfai Kwong]

I need python3 support eagerly..　thank　you.

Anand於 2013年5月16日星期四UTC+8下午9時02分21秒寫道：

[Tomas Schertel]

Hey Anand,  where are you? :)

[Anand Chitipothu]

Yes, I'm around. I've already seen that Armin's article. Lets see how our porting goes.

Anand

 

--
Anand
http://anandology.com/

[Tomas Schertel]

Hi Anand.

I'm just trying  to help you out, ok?

Have you seen these resources?

http://www.getpython3.com/#resources

Any news on migration?

See ya.

[Anand Chitipothu]

Hi Anand.

I'm just trying  to help you out, ok?

Have you seen these resources?

http://www.getpython3.com/#resources

Any news on migration?

Nothing much except deciding that we can drop support for Python<=2.5.

It is very embarrassing to keep you all waiting when many of you are ready to contribute. I'll try to make a plan ready by Monday. We can split tasks and work together.

Anand

[Tomas Schertel]

Sounds great!

[xiaole jianjian]

I think webpy is simple .

[Mark Roberts]

Hey,

I've been following this on and off and so I might have missed it if this conversation split off somewhere else.  Is web.py on github and is there an easy way to contribute pull requests?

-Mark