Re: Anybody use web2py?

Discussion in 'Python' started by mdipierro, Dec 19, 2009.

  1. mdipierro

    mdipierro Guest

    On Dec 19, 12:42 am, AppRe Godeck <> wrote:
    > Just curious if anybody prefers web2py over django, and visa versa. I
    > know it's been discussed on a flame war level a lot. I am looking for a
    > more intellectual reasoning behind using one or the other.


    Of course I am the most biased person in the world on this topic but
    perhaps you want to hear my bias.

    A little bit of history... I thought a Django course at DePaul
    University and built a CMS for the United Nations in Django. I loved
    it. Then I also learned RoR. I found RoR more intuitive and better for
    rapid prototyping. I found Django much faster and more solid. I
    decided to build a proof of concept system that was somewhat in
    between Django and Rails with focus on 3 features: 1) easy to start
    with (no installation, no configuration, web based IDE, web based
    testing, debugging, and database interface); 2) enforce good practice
    (MVC, postbacks); 3) secure (escape all output, talk to database via
    DAL to present injections, server-side cookies with uuid session keys,
    role based access control with pluggable login methods, regex
    validation for all input including URLs).

    Originally it was a proof of concept, mostly suitable for teaching.
    Then lots of people helped to make it better and turn it into a
    production system. Now he had more than 50 contributors and a more
    than 20 companies that provide support.

    There are some distinctive features of web2py vs Django. Some love
    them, some hate hate them (mostly people who did not try them):

    - We promise backward compatibility. I do not accept patches that
    break it. It has been backward compatible for three years and I will
    enforce the copyright, if necessary, in order to ensure it for the
    future.

    - In web2py models and controllers are not modules. They are not
    imported. They are executed. This means you do not need to import
    basic web2py symbols. They are already defined in the environment that
    executes the models and controllers (like in Rails). This also means
    you do not need to restart the web server when you edit your app. You
    can import additional modules and you can define modules if you like.

    - You have a web based IDE with editor, some conflict resolution,
    Mercurial integration, ticketing system, web-based testing and
    debugging.

    - The Database Abstraction Layer (DAL) is closed to SQL than Dango ORM
    is. This means it does less for you (in particular about many 2 many)
    but it is more flaxible when it comes to complex joins, aggregates and
    nested selects.

    - The DAL supports out of the box SQLite, MySQL, PostgreSQL, MSSQL,
    Oracle, FireBird, FireBase, DB2, Informix, Ingres, and the Google App
    Engine (except for joins and multi-entity transactions). We plan
    support for Sybase and MongoDB within one month.

    - The DAL supports transactions. It means it will create and/or ALTER
    tables for you as your model changes. This can be disabled.

    - The DAL has partial support for some legacy databases that do not
    have an 'id' auto increment primary key.

    - It has a plugin and a component systems (here is an old video:
    http://www.vimeo.com/7182692 the video says "experimental" but this is
    now stable in trunk, although not very well documented).

    - both systems have a web based database interface (Django calls it
    "admin", web2py calls it "appadmin, not to be confused with web2py
    "admin", the IDE). The Django one is more polished, customizable and
    designed to be exposed to users. The web2py one is raw and designed
    for the administrator. It is not customizable. Because it is designed
    for the administrator and requires administrator login it allows
    arbitrary DAL code to be executed. It can be disabled.

    Here is the last app I built with it: http://www.vimeo.com/7182692
    running on GAE here: http://www.vimeo.com/7182692


    Here http://www.vimeo.com/6507384 you can see a video in which I
    rewrite the Django polls tutorial in web2py. You will get an idea of
    some of the differences.

    Anyway, I think both system are great. Spend 15 minutes (no more) with
    each to make up your mind, and stick with it.

    Massimo
     
    mdipierro, Dec 19, 2009
    #1
    1. Advertising

  2. mdipierro

    mdipierro Guest

    Errata. I said "The dal supports transactions" where I meant "the dal
    supports migrations".
    Of course it also supports "transactions" as well as "distributed
    transactions".


    On Dec 19, 5:32 pm, mdipierro <> wrote:
    > On Dec 19, 12:42 am, AppRe Godeck <> wrote:
    >
    > > Just curious if anybody prefers web2py over django, and visa versa. I
    > > know it's been discussed on a flame war level a lot. I am looking for a
    > > more intellectual reasoning behind using one or the other.

    >
    > Of course I am the most biased person in the world on this topic but
    > perhaps you want to hear my bias.
    >
    > A little bit of history... I thought a Django course at DePaul
    > University and built a CMS for the United Nations in Django. I loved
    > it. Then I also learned RoR. I found RoR more intuitive and better for
    > rapid prototyping. I found Django much faster and more solid. I
    > decided to build a proof of concept system that was somewhat in
    > between Django and Rails with focus on 3 features: 1) easy to start
    > with (no installation, no configuration, web based IDE, web based
    > testing, debugging, and database interface); 2) enforce good practice
    > (MVC, postbacks); 3) secure (escape all output, talk to database via
    > DAL to present injections, server-side cookies with uuid session keys,
    > role based access control with pluggable login methods, regex
    > validation for all input including URLs).
    >
    > Originally it was a proof of concept, mostly suitable for teaching.
    > Then lots of people helped to make it better and turn it into a
    > production system. Now he had more than 50 contributors and a more
    > than 20 companies that provide support.
    >
    > There are some distinctive features of web2py vs Django. Some love
    > them, some hate hate them (mostly people who did not try them):
    >
    > - We promise backward compatibility. I do not accept patches that
    > break it. It has been backward compatible for three years and I will
    > enforce the copyright, if necessary, in order to ensure it for the
    > future.
    >
    > - In web2py models and controllers are not modules. They are not
    > imported. They are executed. This means you do not need to import
    > basic web2py symbols. They are already defined in the environment that
    > executes the models and controllers (like in Rails). This also means
    > you do not need to restart the web server when you edit your app. You
    > can import additional modules and you can define modules if you like.
    >
    > - You have a web based IDE with editor, some conflict resolution,
    > Mercurial integration, ticketing system, web-based testing and
    > debugging.
    >
    > - The Database Abstraction Layer (DAL) is closed to SQL than Dango ORM
    > is. This means it does less for you (in particular about many 2 many)
    > but it is more flaxible when it comes to complex joins, aggregates and
    > nested selects.
    >
    > - The DAL supports out of the box SQLite, MySQL, PostgreSQL, MSSQL,
    > Oracle, FireBird, FireBase, DB2, Informix, Ingres, and the Google App
    > Engine (except for joins and multi-entity transactions). We plan
    > support for Sybase and MongoDB within one month.
    >
    > - The DAL supports transactions. It means it will create and/or ALTER
    > tables for you as your model changes. This can be disabled.
    >
    > - The DAL has partial support for some legacy databases that do not
    > have an 'id' auto increment primary key.
    >
    > - It has a plugin and a component systems (here is an old video:http://www.vimeo.com/7182692the video says "experimental" but this is
    > now stable in trunk, although not very well documented).
    >
    > - both systems have a web based database interface (Django calls it
    > "admin", web2py calls it "appadmin, not to be confused with web2py
    > "admin", the IDE). The Django one is more polished, customizable and
    > designed to be exposed to users. The web2py one is raw and designed
    > for the administrator. It is not customizable. Because it is designed
    > for the administrator and requires administrator login it allows
    > arbitrary DAL code to be executed. It can be disabled.
    >
    > Here is the last app I built with it:http://www.vimeo.com/7182692
    > running on GAE here:http://www.vimeo.com/7182692
    >
    > Herehttp://www.vimeo.com/6507384you can see a video in which I
    > rewrite the Django polls tutorial in web2py. You will get an idea of
    > some of the differences.
    >
    > Anyway, I think both system are great. Spend 15 minutes (no more) with
    > each to make up your mind, and stick with it.
    >
    > Massimo
     
    mdipierro, Dec 19, 2009
    #2
    1. Advertising

  3. mdipierro

    mdipierro Guest

    Errata 2. Before people jump on me. I said "copyright" but I meant
    "trademark". Of course web2py is GPL2 so everybody can copy and modify
    it.

    The license has an exception that basically treats the compiled web2py
    as freeware.

    The license does not extend to apps that require web2py. They can be
    distributed under any license you like, included closed source and
    bundled with the web2py binary.

    On Dec 19, 5:32 pm, mdipierro <> wrote:
    > On Dec 19, 12:42 am, AppRe Godeck <> wrote:
    >
    > > Just curious if anybody prefers web2py over django, and visa versa. I
    > > know it's been discussed on a flame war level a lot. I am looking for a
    > > more intellectual reasoning behind using one or the other.

    >
    > Of course I am the most biased person in the world on this topic but
    > perhaps you want to hear my bias.
    >
    > A little bit of history... I thought a Django course at DePaul
    > University and built a CMS for the United Nations in Django. I loved
    > it. Then I also learned RoR. I found RoR more intuitive and better for
    > rapid prototyping. I found Django much faster and more solid. I
    > decided to build a proof of concept system that was somewhat in
    > between Django and Rails with focus on 3 features: 1) easy to start
    > with (no installation, no configuration, web based IDE, web based
    > testing, debugging, and database interface); 2) enforce good practice
    > (MVC, postbacks); 3) secure (escape all output, talk to database via
    > DAL to present injections, server-side cookies with uuid session keys,
    > role based access control with pluggable login methods, regex
    > validation for all input including URLs).
    >
    > Originally it was a proof of concept, mostly suitable for teaching.
    > Then lots of people helped to make it better and turn it into a
    > production system. Now he had more than 50 contributors and a more
    > than 20 companies that provide support.
    >
    > There are some distinctive features of web2py vs Django. Some love
    > them, some hate hate them (mostly people who did not try them):
    >
    > - We promise backward compatibility. I do not accept patches that
    > break it. It has been backward compatible for three years and I will
    > enforce the copyright, if necessary, in order to ensure it for the
    > future.
    >
    > - In web2py models and controllers are not modules. They are not
    > imported. They are executed. This means you do not need to import
    > basic web2py symbols. They are already defined in the environment that
    > executes the models and controllers (like in Rails). This also means
    > you do not need to restart the web server when you edit your app. You
    > can import additional modules and you can define modules if you like.
    >
    > - You have a web based IDE with editor, some conflict resolution,
    > Mercurial integration, ticketing system, web-based testing and
    > debugging.
    >
    > - The Database Abstraction Layer (DAL) is closed to SQL than Dango ORM
    > is. This means it does less for you (in particular about many 2 many)
    > but it is more flaxible when it comes to complex joins, aggregates and
    > nested selects.
    >
    > - The DAL supports out of the box SQLite, MySQL, PostgreSQL, MSSQL,
    > Oracle, FireBird, FireBase, DB2, Informix, Ingres, and the Google App
    > Engine (except for joins and multi-entity transactions). We plan
    > support for Sybase and MongoDB within one month.
    >
    > - The DAL supports transactions. It means it will create and/or ALTER
    > tables for you as your model changes. This can be disabled.
    >
    > - The DAL has partial support for some legacy databases that do not
    > have an 'id' auto increment primary key.
    >
    > - It has a plugin and a component systems (here is an old video:http://www.vimeo.com/7182692the video says "experimental" but this is
    > now stable in trunk, although not very well documented).
    >
    > - both systems have a web based database interface (Django calls it
    > "admin", web2py calls it "appadmin, not to be confused with web2py
    > "admin", the IDE). The Django one is more polished, customizable and
    > designed to be exposed to users. The web2py one is raw and designed
    > for the administrator. It is not customizable. Because it is designed
    > for the administrator and requires administrator login it allows
    > arbitrary DAL code to be executed. It can be disabled.
    >
    > Here is the last app I built with it:http://www.vimeo.com/7182692
    > running on GAE here:http://www.vimeo.com/7182692
    >
    > Herehttp://www.vimeo.com/6507384you can see a video in which I
    > rewrite the Django polls tutorial in web2py. You will get an idea of
    > some of the differences.
    >
    > Anyway, I think both system are great. Spend 15 minutes (no more) with
    > each to make up your mind, and stick with it.
    >
    > Massimo
     
    mdipierro, Dec 20, 2009
    #3
  4. mdipierro

    Lacrima Guest

    On Dec 20, 1:35 am, mdipierro <> wrote:
    > Errata. I said "The dal supports transactions" where I meant "the dal
    > supports migrations".
    > Of course it also supports "transactions" as well as "distributed
    > transactions".



    Sorry, if this is not related to this topic.
    Does web2py support distributed transactions with Google App Engine
    Datastore?
     
    Lacrima, Dec 20, 2009
    #4
  5. mdipierro

    mdipierro Guest

    The concept of distributed transaction does not make sense on GAE
    because there is only one datastore.

    It supports regular transactions on GAE to the extent that GAE
    supports them but you have to use the GAE run_in_transaction API
    explictely.

    It does support distributed transactions with multiple database
    connection to postgresq, mysql and/or firebird.
    I think this is related to the topic because it is a distinctive
    feature of web2py.

    Massimo

    On Dec 20, 1:32 pm, Lacrima <> wrote:
    > On Dec 20, 1:35 am, mdipierro <> wrote:
    >
    > > Errata. I said "The dal supports transactions" where I meant "the dal
    > > supports migrations".
    > > Of course it also supports "transactions" as well as "distributed
    > > transactions".

    >
    > Sorry, if this is not related to this topic.
    > Does web2py support distributed transactions with Google App Engine
    > Datastore?
     
    mdipierro, Dec 20, 2009
    #5
  6. mdipierro a écrit :
    > On Dec 19, 12:42 am, AppRe Godeck <> wrote:
    >> Just curious if anybody prefers web2py over django, and visa versa. I
    >> know it's been discussed on a flame war level a lot. I am looking for a
    >> more intellectual reasoning behind using one or the other.

    >
    > Of course I am the most biased person in the world on this topic


    Indeed !-)

    >
    > - In web2py models and controllers are not modules. They are not
    > imported. They are executed.


    I assume you mean "executed in an environment defined by the framework"...

    > This means you do not need to import
    > basic web2py symbols. They are already defined in the environment that
    > executes the models and controllers


    Ok. As far as I'm concerned : show stops here.

    >(like in Rails). This also means
    > you do not need to restart the web server when you edit your app.


    The dev server that comes with Django do the autorestart thing. And you
    *don't* "edit yoour app" directly on the production server, do you ?

    > - You have a web based IDE with editor,


    Why should I care ? I have a way better development environment on my
    own box.

    > some conflict resolution,
    > Mercurial integration,


    What if use something else than mercurial ?

    > ticketing system,


    ....doesn't belong to the framework. FWIW, I already have a ticketing
    system that's language/techno agnostic, thanks.

    >
    > - The DAL supports transactions. It means it will create and/or ALTER
    > tables for you as your model changes.


    Err... how does schema changes relates to transactions ???

    Now FWIW, when my schema do change, the create/alter table code is
    usually the most trivial part - there are quite a few other things to
    do, that no framework will ever be abale to guess. IOW, you *do* have to
    write a migration script anyway.

    >
    > - The DAL has partial support for some legacy databases that do not
    > have an 'id' auto increment primary key.


    Django's ORM has full support for tables that don't use an "auto_id" key.


    > Anyway, I think both system are great. Spend 15 minutes (no more) with
    > each to make up your mind, and stick with it.


    Once again, while doing a quick dummy test app can give you a first
    general "feel" of the tool, it means nothing wrt/ complex real-world
    applications.
     
    Bruno Desthuilliers, Dec 21, 2009
    #6
  7. mdipierro

    mdipierro Guest

    > > On Dec 19, 12:42 am, AppRe Godeck <> wrote:
    > >> Just curious if anybody prefers web2py over django, and visa versa. I
    > >> know it's been discussed on a flame war level a lot. I am looking for a
    > >> more intellectual reasoning behind using one or the other.

    >
    > > Of course I am the most biased person in the world on this topic

    >
    > Indeed !-)
    > > - In web2py models and controllers are not modules. They are not
    > > imported. They are executed.

    >
    > I assume you mean "executed in an environment defined by the framework"...


    yes

    > > This means you do not need to import
    > > basic web2py symbols. They are already defined in the environment that
    > > executes the models and controllers

    >
    > Ok. As far as I'm concerned : show stops here.


    It is your choice but, why?
    Exec/eval is only true distinctive feature of an interpreted language
    vs a compiled language.

    > >(like in Rails). This also means
    > > you do not need to restart the web server when you edit your app.

    >
    > The dev server that comes with Django do the autorestart thing. And you
    > *don't* "edit yoour app" directly on the production server, do you ?


    Unfortunately it has happened.
    In my experience the distinction between development and production is
    fiction.

    > > - You have a web based IDE with editor,

    >
    > Why should I care ? I have a way better development environment on my
    > own box.


    I only use emacs. I do not use the web based IDE much myself but I
    found it really helps in learning how to use the framework.

    > > some conflict resolution,
    > > Mercurial integration,

    >
    > What if use something else than mercurial ?


    You can use any version control you want, the same way you would in
    Django. web2py itself is version controlled in both bazaar and
    mercurial. The only think about mercurial is that, if you have it
    installed, the web based IDE lets you commit at the click on a
    <button>.

    > > ticketing system,

    >
    > ...doesn't belong to the framework. FWIW, I already have a ticketing
    > system that's language/techno agnostic, thanks.


    Perhaps we are not talking about the same thing. if an error occurs in
    a web2py application and I want: 1) notify the user, 2) assign the
    user a ticket number; 3) log the error in the framework; 4) allow
    administrator to browse past error logs; I think this belongs to the
    framework else it gets clunky. Web2py tickets are out of the box and
    always on.

    > > - The DAL supports transactions. It means it will create and/or ALTER
    > > tables for you as your model changes.

    >
    > Err... how does schema changes relates to transactions ???


    Type "migrations" not "transactions" sorry.

    > Now FWIW, when my schema do change, the create/alter table code is
    > usually the most trivial part - there are quite a few other things to
    > do, that no framework will ever be abale to guess. IOW, you *do* have to
    > write a migration script anyway.


    No. We do not have migration scripts. It is nothing like Rails. You
    just edit a model and, voila', database is migrated. Nothing to type.
    Nothing to click on. (you can disable it)

    I respect you choosing Django but it looks like you have never tried
    web2py.

    > > - The DAL has partial support for some legacy databases that do not
    > > have an 'id' auto increment primary key.

    >
    > Django's ORM has full support for tables that don't use an "auto_id" key.


    web2py too has support for legacy databases for tables without an
    auto_id but not yet for all database back-ends.

    > > Anyway, I think both system are great. Spend 15 minutes (no more) with
    > > each to make up your mind, and stick with it.

    >
    > Once again, while doing a quick dummy test app can give you a first
    > general "feel" of the tool, it means nothing wrt/ complex real-world
    > applications.


    While this may be true as a general statement could you explain which
    feature you find in Django that is not in web2py and that is is
    crytical for building large web applications? Could you provide a
    coding example of such feature? This is an honest question because it
    can help us make web2py better. I have personally learned a lot from
    Django and thank the Django developers for their work, I would be
    happy to learn more.

    Massimo
     
    mdipierro, Dec 21, 2009
    #7
  8. mdipierro

    Yarko Guest

    On Dec 21, 2:50 am, Bruno Desthuilliers <bruno.
    > wrote:
    > mdipierro a écrit :

    ....
    > > This means you do not need to import
    > > basic web2py symbols. They are already defined in the environment that
    > > executes the models and controllers

    >
    > Ok. As far as I'm concerned : show stops here.


    Sorry- I don't _think_ I'm following: If you want to write an app all
    yourself, and use components to put it together, that's fine - more
    control, and more responsibility (e.g. watch for security, etc.).

    But most web applications simply do not require or justify this much
    effort spent on this level of "responsibility"; but maybe I'm missing
    something less obvious that you mean, that makes "the show stop here"
    for you. If so, maybe you can be a bit more explicit about it.

    .....
    >
    > > - You have a web based IDE with editor,

    >
    > Why should I care ? I have a way better development environment on my
    > own box.
    >


    For example, on a running system, simple things are possible simply:
    change the cutoff date on something; change a class size. Yeah, sure
    - my app could write a controller for all those _little_ unanticipated
    tweaks that inevitably come, but why bother? You can just do it with
    existing environment: Want 100 coupons for that vendor? No problem
    (lets say that's in a controller). Want to make it a special thingy
    for that special vendor - put his image on his coupons? his words and
    instructions? Ok - I suppose i might have written a wiki interface so
    someone can do this one thing, this one time - but (again) why
    bother? I'll do it thru the dev. interface on a running system. If
    I'm convinced it was an un-captured requirement (e.g. no one thought
    of it until the system was running, or it was "assumed" but somehow
    missed by everyone) then I'll write the associated code, and add it
    to the running system. In fact, this is quite an agile way to do
    it. Both the dev. environ, and the command line shell help in this
    (I can write a small loop in the shell to effect what might be a
    controller for a customer, and output to a file instead of a view, and
    ask the customer "Is this what you're looking for?" - tweak, confirm
    happy client, and then put the code I just used into a controller - if
    it's short enough, right in the interface on the running system, and
    have the client try it while we're still on the phone/IM/whatever.

    The things I didn't think would be that useful - proved to have useful
    application.


    .......
    >
    > Now FWIW, when my schema do change, the create/alter table code is
    > usually the most trivial part - there are quite a few other things to
    > do, that no framework will ever be abale to guess. IOW, you *do* have to
    > write a migration script anyway.


    In practice, this is /should be much less than you would think...
    ADDING columns to tables is simple.
    REMOVING columns... perhaps unnecessary on running systems...
    ALTERING columns... can probably be handled instead by adding.

    I think for most useful (and certain development time) cases, the
    framework can do reasonable things, usefully. But I do not deny that
    there are cases where there is not way around doing things smarter
    than that. I think it is just that there are times where that is not
    as necessary as at first appears.


    ......
    >
    > Once again, while doing a quick dummy test app can give you a first
    > general "feel" of the tool, it means nothing wrt/ complex real-world
    > applications.


    Actually, I agree - and I would go a bit further: NO FRAMEWORK / tool
    has anything much to do wrt/ complex real-world apps. In fact, at the
    framework / coding level, things should be as simple as possible (that
    is where the cost is, anyway).

    Good analysis of the problem domain will suggest the shape of the
    solution needed. Prototyping will then help with things like "can it
    be a web app?" and "what technologies / implementation languages are
    appropriate?" Once you're at that stage, _any tool_ (and most likely,
    combination of tools / set of tools) come into play: what do they do
    to help at this level, how do they enable the process you want to
    follow, how do they get out of the way. Are they too rigid (too many
    defaults / too few options for a given solution decision)?

    But this is so far down the path of designing a solution that "complex
    real-world" doesn't fitthis discussion, without getting more specific,
    e.g. _a_ specific real-world app. For PyCon, web2py registration was
    done, reviewed, and put into place with little more than a month's
    worth of discussion / prep. Yeah, it didn't "look" like the main
    PyCon site the first year (and didn't take much at all to change that
    when I decided to). Yeah, there are still details about integrating
    w/ the django part of the site that could be taken care of from the
    web2py end (I don't know, but was lead to believe it would be easier
    from the web2py end than the django end, e.g. multiple database
    connections). As with many projects, if it is volunteer programming,
    and if it's _really_ important, it will happen, or if someone _really_
    wants to do it - otherwise it's not evidence of anything more than
    something that's not really all that important. A few years ago,
    there was a challenge app (build a survey building app) that web2py
    finished, and donated in < 24 hrs; no one else either completed, knew
    of, or whatever - point is, if you _really_ want to make claims like
    this, then setup an essential ingredient that you are convinced is
    really beneficial - define it such that everyone agrees that it's a
    good definition: it will either be a key deciding point (and helpful
    to the community - "a does this; b does not"), or it will be a
    challenge point that can be tested (e.g. two solution approaches can
    be devised by "those who know the tools", and inspected and reviewed
    by the community - also helpful). Anything else is just opinion and
    talk - and to be sure, there is room for opinion, talk, and
    preferences (no one really _needs_ to convince a Ford owner to drive a
    Chevy - until some level of bankruptcy happens, it really doesn't
    matter). But even there, it is a benefit to the community in general
    to separate the talk from the real deciding factors. Thankfully,
    preference will always play a part.

    Kind regards,
    - Yarko
     
    Yarko, Dec 21, 2009
    #8
  9. mdipierro

    mdipierro Guest

    Some may find useful to compare:

    - A Crash Course on Django
    http://articles.sitepoint.com/article/django-crash-course

    - A Crash Course on Web2py
    http://www.web2py.com/AlterEgo/default/show/253

    They basically describe the same app and the steps to built it. Sorry
    I had not time to make screenshots.

    I personally think it is great that we can learn from each other from
    this kind of comparison and we can both improve.
    I also think that stressing the similarities and the differences will
    help prospective users understand the underlying design patterns.

    Massimo
     
    mdipierro, Dec 22, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steve Shephed
    Replies:
    2
    Views:
    659
    mdipierro
    Sep 23, 2008
  2. Yarko

    Re: Anybody use web2py?

    Yarko, Dec 19, 2009, in forum: Python
    Replies:
    9
    Views:
    840
    Yarko
    Dec 21, 2009
  3. Anand Vaidya

    Re: Anybody use web2py?

    Anand Vaidya, Dec 20, 2009, in forum: Python
    Replies:
    1
    Views:
    407
    Bruno Desthuilliers
    Dec 21, 2009
  4. Abhinav Sood

    Re: Anybody use web2py?

    Abhinav Sood, Mar 3, 2011, in forum: Python
    Replies:
    0
    Views:
    774
    Abhinav Sood
    Mar 3, 2011
  5. Paul Watson

    Django or web2py

    Paul Watson, Sep 8, 2011, in forum: Python
    Replies:
    3
    Views:
    2,050
    Vineet
    Sep 9, 2011
Loading...

Share This Page