Re: choice of web-framework

[John Black]

In article , 
ros...@gmail.com says...
> 
> On Tue, Oct 24, 2017 at 6:57 AM, Chris Warrick  wrote:
> > On 23 October 2017 at 21:37, John Black  wrote:
> >> Chris, thanks for all this detailed information.  I am confused though
> >> with your database recommendation.  You say you teach SQLAlchemy but
> >> generally use PostgreSQL yourself.  I can maybe guess why there seems to
> >> be this contradiction.  Perhaps PostgreSQL is better but too advanced for
> >> the class you are teaching?  Can you clarify on which you think is the
> >> better choice?  Thanks.
> >
> > Different Chris, but I?ll answer. Those are two very different things.
> >
> > PostgreSQL is a database server. It talks SQL to clients, stores data,
> > retrieves it when asked. The usual stuff a database server does.
> > Alternatives: SQLite, MySQL, MS SQL, Oracle DB, ?
> >
> > SQLAlchemy is an ORM: an object-relational mapper, and also a database
> > toolkit. SQLAlchemy can abstract multiple database servers/engines
> > (PostgreSQL, SQLite, MySQL, etc.) and work with them from the same
> > codebase. It can also hide SQL from you and instead give you Python
> > classes. If you use an ORM like SQLAlchemy, you get database support
> > without writing a single line of SQL on your own. But you still need a
> > database engine ? PostgreSQL can be one of them. But you can deploy
> > the same code to different DB engines, and it will just work?
> > (assuming you didn?t use any DB-specific features). Alternatives:
> > Django ORM.
> >
> > psycopg2 is an example of a PostgreSQL client library for Python. It
> > implements the Python DB-API and lets you use it to talk to a
> > PostgreSQL server. When using psycopg2, you?re responsible for writing
> > your own SQL statements for the server to execute. In that approach,
> > you?re stuck with PostgreSQL and psycopg2 unless you rewrite your code
> > to be compatible with the other database/library. Alternatives (other
> > DBs): sqlite3, mysqlclient. There are also other PostgreSQL libraries
> > available.
> >
> 
> Thanks, namesake :)
> 
> The above is correct and mostly accurate. It IS possible to switch out
> your back end fairly easily, though, even with psycopg2; there's a
> standard API that most Python database packages follow. As long as you
> stick to standard SQL (no PostgreSQL extensions) and the standard API
> (no psycopg2 extensions), switching databases is as simple as changing
> your "import psycopg2" into "import cx_oracle" or something. (And,
> most likely, changing your database credentials.)
> 
> The point of an ORM is to make your databasing code look and feel like
> Python code, rather than manually crafting SQL statements everywhere.
> Here's how a simple database operation looks in SQLAlchemy:

Thank you Chris and Chris!

John Black
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[justin walters]

On Tue, Oct 24, 2017 at 4:14 AM, Chris Angelico  wrote:

>
> (There are other ORMs than SQLAlchemy, of course; I can't recall the
> exact syntax for Django's off the top of my head, but it's going to be
> broadly similar to this.)
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>


I can help with that:

## Defining a model:

class Thing(models.Model):
"""
This is the "schema" for the `thing` table. The pk field is created
automatically and is called `id` by default. This table with have
four columns: `id`, `foo`, `baz`, and `score`.
"""
foo = models.Charfield(
max_length=140,
blank=False
)
baz = models.CharField(
max_length=140,
blank=True
)
score = models.IntegerField()

## Create an object:

new_thing = Thing.objects.create(foo="bar", baz="foo")

## Get a list of objects:

Thing.objects.all()

## Filter a list of objects:

Thing.objects.filter(foo="bar")

## Modify an object:

thing = Thing.objects.get(id=1)
thing.foo = "baz"
thing.save()

## Perform an aggregation:

data = Thing.objects.aggregate(avg=Avg("score"))
print(data)
>>> {"avg": 50}

## Django basic view(called controllers in other frameworks normally) and
template:

def person_list(request):
"""
Get a collection of `User` objects from the database.
"""
people = User.objects.filter(is_active=True).order_by("date_joined")
return render(
request,
"person/list.html",
context={"people": people}
)


Then, in `templates/person/list.html`:

{% extends 'base.html' %}

{% block content %}

{% for person in people %}

{{person.first_name}} {{person.last_name}}

{% endfor %}

{% endblock %}


Alternatives to Django's ORM and SQLAlchemy include but are not limited to:

- Peewee: https://github.com/coleifer/peewee
- PonyORM: https://ponyorm.com/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Chris Angelico]

On Tue, Oct 24, 2017 at 6:57 AM, Chris Warrick  wrote:
> On 23 October 2017 at 21:37, John Black  wrote:
>> Chris, thanks for all this detailed information.  I am confused though
>> with your database recommendation.  You say you teach SQLAlchemy but
>> generally use PostgreSQL yourself.  I can maybe guess why there seems to
>> be this contradiction.  Perhaps PostgreSQL is better but too advanced for
>> the class you are teaching?  Can you clarify on which you think is the
>> better choice?  Thanks.
>
> Different Chris, but I’ll answer. Those are two very different things.
>
> PostgreSQL is a database server. It talks SQL to clients, stores data,
> retrieves it when asked. The usual stuff a database server does.
> Alternatives: SQLite, MySQL, MS SQL, Oracle DB, …
>
> SQLAlchemy is an ORM: an object-relational mapper, and also a database
> toolkit. SQLAlchemy can abstract multiple database servers/engines
> (PostgreSQL, SQLite, MySQL, etc.) and work with them from the same
> codebase. It can also hide SQL from you and instead give you Python
> classes. If you use an ORM like SQLAlchemy, you get database support
> without writing a single line of SQL on your own. But you still need a
> database engine — PostgreSQL can be one of them. But you can deploy
> the same code to different DB engines, and it will just work™
> (assuming you didn’t use any DB-specific features). Alternatives:
> Django ORM.
>
> psycopg2 is an example of a PostgreSQL client library for Python. It
> implements the Python DB-API and lets you use it to talk to a
> PostgreSQL server. When using psycopg2, you’re responsible for writing
> your own SQL statements for the server to execute. In that approach,
> you’re stuck with PostgreSQL and psycopg2 unless you rewrite your code
> to be compatible with the other database/library. Alternatives (other
> DBs): sqlite3, mysqlclient. There are also other PostgreSQL libraries
> available.
>

Thanks, namesake :)

The above is correct and mostly accurate. It IS possible to switch out
your back end fairly easily, though, even with psycopg2; there's a
standard API that most Python database packages follow. As long as you
stick to standard SQL (no PostgreSQL extensions) and the standard API
(no psycopg2 extensions), switching databases is as simple as changing
your "import psycopg2" into "import cx_oracle" or something. (And,
most likely, changing your database credentials.)

The point of an ORM is to make your databasing code look and feel like
Python code, rather than manually crafting SQL statements everywhere.
Here's how a simple database operation looks in SQLAlchemy:

def spammify(id):
person = session.query(Person).get(id)
person.style = "spam"
session.commit()

Here's the equivalent using psycopg2:

def spammify(id):
with db, db.cursor() as cur:
cur.execute("update people set style='spam' where id=%s", id)

With SQLAlchemy, you ask for a particular record, and you get back an
object. That object has attributes for all the person's information,
and you can both read and write those attributes. Then you commit when
you're done. Without SQLAlchemy, you use another language (SQL),
embedded within your Python code.

The choice is mostly one of style and preference. But if you don't
currently have a preference, I would recommend using an ORM.

(There are other ORMs than SQLAlchemy, of course; I can't recall the
exact syntax for Django's off the top of my head, but it's going to be
broadly similar to this.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Chris Warrick]

On 23 October 2017 at 21:37, John Black  wrote:
> Chris, thanks for all this detailed information.  I am confused though
> with your database recommendation.  You say you teach SQLAlchemy but
> generally use PostgreSQL yourself.  I can maybe guess why there seems to
> be this contradiction.  Perhaps PostgreSQL is better but too advanced for
> the class you are teaching?  Can you clarify on which you think is the
> better choice?  Thanks.

Different Chris, but I’ll answer. Those are two very different things.

PostgreSQL is a database server. It talks SQL to clients, stores data,
retrieves it when asked. The usual stuff a database server does.
Alternatives: SQLite, MySQL, MS SQL, Oracle DB, …

SQLAlchemy is an ORM: an object-relational mapper, and also a database
toolkit. SQLAlchemy can abstract multiple database servers/engines
(PostgreSQL, SQLite, MySQL, etc.) and work with them from the same
codebase. It can also hide SQL from you and instead give you Python
classes. If you use an ORM like SQLAlchemy, you get database support
without writing a single line of SQL on your own. But you still need a
database engine — PostgreSQL can be one of them. But you can deploy
the same code to different DB engines, and it will just work™
(assuming you didn’t use any DB-specific features). Alternatives:
Django ORM.

psycopg2 is an example of a PostgreSQL client library for Python. It
implements the Python DB-API and lets you use it to talk to a
PostgreSQL server. When using psycopg2, you’re responsible for writing
your own SQL statements for the server to execute. In that approach,
you’re stuck with PostgreSQL and psycopg2 unless you rewrite your code
to be compatible with the other database/library. Alternatives (other
DBs): sqlite3, mysqlclient. There are also other PostgreSQL libraries
available.

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[John Black]

In article , 
ros...@gmail.com says...
> For the database, I generally use PostgreSQL, unless the job's so
> simple it can be done with flat files. Using Flask with SQLAlchemy is
> a popular option, but you can also dive into psycopg2 directly (the
> "2" doesn't mean "Python 2.7 only", it's fine). The tech stack
> Python+Flask+SQLAlchemy+PostgreSQL+Linux is an extremely solid one, or
> you can switch out any part fairly easily.
> 
> Disclaimer: I use Flask and SQLAlchemy when I'm teaching my students
> how to build web apps in Python, but I don't have much experience with
> any other frameworks or ORMs. Other options may very well be viable
> and/or superior; all I can say is that the above *is* viable.

Chris, thanks for all this detailed information.  I am confused though 
with your database recommendation.  You say you teach SQLAlchemy but 
generally use PostgreSQL yourself.  I can maybe guess why there seems to 
be this contradiction.  Perhaps PostgreSQL is better but too advanced for  
the class you are teaching?  Can you clarify on which you think is the 
better choice?  Thanks.

John Black
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Kevin van Keeken]

Greetings,

while reading through this topic i would like to know, if cherrypy is a
viable web-framework as well?

I stumbled upon this project a while ago, but didn't read through it in
detail and would like to hear something about it, especially in regards
to the project requirements.

Kind regards

> Patrick Vrijlandt  writes:
>> ...
>> The project is completely new, there are no histories to take into
>> account (current solutions are paper-based). The website involves
>> questionnaires that will be developed, filled out and stored. Users
>> are not programmers or developers. They should be
>> authenticated. Version control is required. Internationalization is
>> not an issue. I expect that the project will add additional
>> requirements and complexity later on that I can not foresee yet. I'm
>> targeting a single deployment (maybe a second on a development
>> machine). I usually work on Windows, but Linux can be considered.
> I am using Plone (a CMS (= Content Management System) build on top of
> Zope) for something like this. It has a standard extension
> "CMFEditions" for version control of its content.
>
> The content is managed in the Zope Object Database (= "ZODB"). This is
> also valid for the revisions. Thus, you do not get
> "git/mercurial/..."-style version control (based on files) but
> you see when and by whom a version was created, can revert to a
> previous version and see differences between versions. There is no
> merge support, though.
>
> The standard Plone content types are likely not sufficient to
> implement your questionnaires; you will probably define one of
> more specific for your task. But, this is not too complex.
>
> Questions about Plone (and the underlying Zope) can be asked at
> "https://community.plone.org/;.
>
>

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[dieter]

Patrick Vrijlandt  writes:
> ...
> The project is completely new, there are no histories to take into
> account (current solutions are paper-based). The website involves
> questionnaires that will be developed, filled out and stored. Users
> are not programmers or developers. They should be
> authenticated. Version control is required. Internationalization is
> not an issue. I expect that the project will add additional
> requirements and complexity later on that I can not foresee yet. I'm
> targeting a single deployment (maybe a second on a development
> machine). I usually work on Windows, but Linux can be considered.

I am using Plone (a CMS (= Content Management System) build on top of
Zope) for something like this. It has a standard extension
"CMFEditions" for version control of its content.

The content is managed in the Zope Object Database (= "ZODB"). This is
also valid for the revisions. Thus, you do not get
"git/mercurial/..."-style version control (based on files) but
you see when and by whom a version was created, can revert to a
previous version and see differences between versions. There is no
merge support, though.

The standard Plone content types are likely not sufficient to
implement your questionnaires; you will probably define one of
more specific for your task. But, this is not too complex.

Questions about Plone (and the underlying Zope) can be asked at
"https://community.plone.org/;.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Abdur-Rahmaan Janhangeer]

have you considered Django? i've found found it to be nice !

Abdur-Rahmaan Janhangeer,
Mauritius
abdurrahmaanjanhangeer.wordpress.com

On 22 Oct 2017 14:25, "Patrick Vrijlandt"  wrote:

> Hello list,
>
> I would like your recommendation on the choice of a web framework.
>
> The project is completely new, there are no histories to take into account
> (current solutions are paper-based). The website involves questionnaires
> that will be developed, filled out and stored. Users are not programmers or
> developers. They should be authenticated. Version control is required.
> Internationalization is not an issue. I expect that the project will add
> additional requirements and complexity later on that I can not foresee yet.
> I'm targeting a single deployment (maybe a second on a development
> machine). I usually work on Windows, but Linux can be considered.
>
> I'm not afraid to learn a (=one) new framework (that would actually be
> fun) but trying out a lot of them is not feasible. My current goal is a
> demonstration version of the project as a proof of concept. I may want to
> hand it over to a commercial solution at that stage.
>
> I'm an experienced python programmer but not an experienced web developer.
> A few years ago I read some books about Zope and Plone, but never did
> serious development with those. I currently maintain an intranet site in
> MoinMoin. I assume Zope could still be a potential choice, but it may have
> lost the vibrancy of a few years ago. Also, I would not know which version
> to choose (Zope 4, BlueBream, or something like Grok). The problem seems
> too complicated for micro frameworks like bottle of Flask. Django could be
> the next alternative.
>
> Finally, for a new project, I would not like to be confined to Python 2.7.
>
> What are your ideas?
>
> Thanks in advance,
>
> --
> Patrick
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Tim Chase]

On 2017-10-22 15:26, Patrick Vrijlandt wrote:
> The version control I was referring to, is indeed users' data. I
> plan to use Mercurial for the source code. The questionnaires being
> developed will go through many revisions. The questionnaires being
> filled in, are enough work to have a provision for mistakes. The
> idea is much like the "revert" option that MoinMoin and other wikis
> provide.

Depends on how much version-control'y'ness you want.  Having a
"current version with previous version" and if "resurrect version
$CURRENT-$N as the most recent version" is sufficient, then it's
pretty straight-forward.  If you also want to implement diffing,
merging diffs between various versions, diffing more than a single
text-field blob (a model spread across multiple normalized tables,
versioning changes there), etc, you're looking at a whole different
game.

Additionally, one needs to consider how responses get tied to a
questionnaire.  If I make a questionnaire that reads

 "Do you like ice cream?"
 [ ] Yes
 [ ] No

and you answer "Yes", but then I edit that question so that it reads

 "Do you like to kick puppies?"

you have a problem if it keeps your "Yes" answer and thinks it's
linked to the "same" question.

All that to say that version-control is often domain-specific and
non-trivial.

-tkc



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[justin walters]

On Sun, Oct 22, 2017 at 3:24 AM, Patrick Vrijlandt 
wrote:

> Hello list,
>
> I would like your recommendation on the choice of a web framework.
>
> The project is completely new, there are no histories to take into account
> (current solutions are paper-based). The website involves questionnaires
> that will be developed, filled out and stored. Users are not programmers or
> developers. They should be authenticated. Version control is required.
> Internationalization is not an issue. I expect that the project will add
> additional requirements and complexity later on that I can not foresee yet.
> I'm targeting a single deployment (maybe a second on a development
> machine). I usually work on Windows, but Linux can be considered.
>
> I'm not afraid to learn a (=one) new framework (that would actually be
> fun) but trying out a lot of them is not feasible. My current goal is a
> demonstration version of the project as a proof of concept. I may want to
> hand it over to a commercial solution at that stage.
>
> I'm an experienced python programmer but not an experienced web developer.
> A few years ago I read some books about Zope and Plone, but never did
> serious development with those. I currently maintain an intranet site in
> MoinMoin. I assume Zope could still be a potential choice, but it may have
> lost the vibrancy of a few years ago. Also, I would not know which version
> to choose (Zope 4, BlueBream, or something like Grok). The problem seems
> too complicated for micro frameworks like bottle of Flask. Django could be
> the next alternative.
>
> Finally, for a new project, I would not like to be confined to Python 2.7.
>
> What are your ideas?
>
> Thanks in advance,
>
> --
> Patrick
> --
> https://mail.python.org/mailman/listinfo/python-list
>

I think your best choice here would be Django. I've been doing web
development with Python
for about 5 years now and I have only found thing that Django can't handle:
replacing the authentication
framework's dependence on SQL. i.e., if you wanted to use a noSQL db like
MongoDb for your user
model, it's not really possible without a ton of work. Other than that
though, Django can pretty much do everything.

Since you need to get this prototype done quickly, I think Django is your
absolute best choice. The projects motto is
"The web framework for perfectionists with deadlines." You get a ton of
stuff out of the box:

- User authentication
- Sessions
- Admin interface
- Fantastic ORM
- Templating (like jinbja2 but with some Django flair)
- The best documentation I have ever seen
- A huge ecosystem of third party libraries and plugins
- A strong and heavilly opinionated MVC architecture
- One of ths strongest and best suppported OSS projects in existence
- Built in and versioned schema migrations

The reasons I would not reccomend Flask/Bottle for your project
specifically:

- Flask is better for more "customized" solutions or simpler projects
- Flask is a great framework, but offers very little out of the box as far
as modern web application features
- It takes longer to get rolling with Flask(a lot more initial
configuration)
- When using Flask, many devs end up building their own version of Django
anyways
- Flask's tutorial is a lot less in-depth than Django's
- Although learning Flask in its entirety is much simpler than learning
Django in its entirety, it takes more time
  to get up and running with Flask in my experience.

Web2py/zope/other small and old frameworks:

- I would stay away from these unless you have a lot of experience with
them.
- These projects do not have a modern ecosystem of libraries and may not
have full Python3 support
- You will find less community memebers that are able to help you as there
are less people using these frameworks

Hug/Sanic/Falcon/ApiStar:

- These are designed around the idea of REST apis
- They offer less than Flask does out of the box(except for building REST
apis)
- They are fairly new and have not had the time to build up a supportive
ecosystem yet
- They rely on new language features like async
- Their docs are not up to par with more mature projects

Pyramid:

Though I haven't ever worked with Pyramid, I have met several people who
are very happy with it. I also met with
one of the project's core contributors and he spoke about how the
architecture is "plugin based". There is the the core library
and all of the other layers of the application such as the data layer or
authentication, for example, are officially supported
plugins. Might be worth looking into.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Chris Angelico]

On Mon, Oct 23, 2017 at 12:26 AM, Patrick Vrijlandt  wrote:
> Op 22-10-2017 om 14:05 schreef Tim Chase:
>
>> I'm not sure what "version control is required" means in this
>> context.  Is this version-control of the users' answers? Or
>> version-control of the source code.  If it's the source code, the web
>> framework won't help you there, but git, mercurial, or subversion are
>> all good/reasonable choices.  If you want to version your user's
>> answers or other aspects of your application, you'll need to design
>> it into your app.  There might be plugins/modules to facilitate this
>> on either side of the Django / Flask/Bottle/SQLAlchemy divide.
>
> The version control I was referring to, is indeed users' data. I plan to use
> Mercurial for the source code. The questionnaires being developed will go
> through many revisions. The questionnaires being filled in, are enough work
> to have a provision for mistakes. The idea is much like the "revert" option
> that MoinMoin and other wikis provide.

Then what I'd do is make sure the questionnaires are saved in a text
file (maybe use a Markdown-like notation), and then just call on
Mercurial from inside your app.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Patrick Vrijlandt]

Op 22-10-2017 om 14:05 schreef Tim Chase:

> I'm not sure what "version control is required" means in this
> context.  Is this version-control of the users' answers? Or
> version-control of the source code.  If it's the source code, the web
> framework won't help you there, but git, mercurial, or subversion are
> all good/reasonable choices.  If you want to version your user's
> answers or other aspects of your application, you'll need to design
> it into your app.  There might be plugins/modules to facilitate this
> on either side of the Django / Flask/Bottle/SQLAlchemy divide.

The version control I was referring to, is indeed users' data. I plan to 
use Mercurial for the source code. The questionnaires being developed 
will go through many revisions. The questionnaires being filled in, are 
enough work to have a provision for mistakes. The idea is much like the 
"revert" option that MoinMoin and other wikis provide.


--Patrick
--
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Tim Chase]

On 2017-10-22 12:24, Patrick Vrijlandt wrote:
> I would like your recommendation on the choice of a web framework.

Might depend on what skills you already bring to the table.  If you
already know an ORM like SQLAlchemy or a template language like
Jinja, you might want to take the "bring the pieces I know/like
together" approach.  For this, Bottle & Flask are the top contenders
last I saw (I did some CherryPy contract work but the docs were
pretty horrible at the time).

If you are genuinely coming to this greenfield, Django's
docs/tutorials make it really easy to get up to speed with all of the
parts involved as it has its own ORM and templating language.  They
can be swapped out if you later need to, but for the average project,
they're sufficient and well documented.

I happen to be in the Django camp, but based on my experiments with
Bottle/Flask, can also recommend them without much hesitation.

> The project is completely new, there are no histories to take into 
> account (current solutions are paper-based). The website involves 
> questionnaires that will be developed, filled out and stored. Users
> are not programmers or developers. They should be authenticated.
> Version control is required.

I'm not sure what "version control is required" means in this
context.  Is this version-control of the users' answers? Or
version-control of the source code.  If it's the source code, the web
framework won't help you there, but git, mercurial, or subversion are
all good/reasonable choices.  If you want to version your user's
answers or other aspects of your application, you'll need to design
it into your app.  There might be plugins/modules to facilitate this
on either side of the Django / Flask/Bottle/SQLAlchemy divide.

> I'm targeting a single deployment (maybe a second on a
> development machine). I usually work on Windows, but Linux can be
> considered.

While both *can* be deployed on Windows, a Unix-like OS (whether
Linux, a BSD, or even a Mac) will likely give you a better deployment
experience and better docs.

> I'm not afraid to learn a (=one) new framework (that would actually
> be fun) but trying out a lot of them is not feasible. My current
> goal is a demonstration version of the project as a proof of
> concept.

I personally find that Django excels at these fast proof-of-concept
projects, as you have less concern about integrating disparate pieces
together at that stage.

> I'm an experienced python programmer but not an experienced web 
> developer.

Both sides offer a "Pythonic" feel to them (some feel less Pythonic)
so it's easy to come up to speed on either.

> A few years ago I read some books about Zope and Plone,

Hah, Zope was my first introduction to Python and I ran screaming.  I
eventually came back around, but it was a jarring first experience.

> The problem seems too complicated for micro frameworks like bottle
> of Flask. Django could be the next alternative.

Django is the top contender, so if you only have time to investigate
one, I'd urge you in that direction.  But Flask or Bottle can also
certainly handle a project like the one you describe.

> Finally, for a new project, I would not like to be confined to
> Python 2.7.

Flask/Bottle and Django are both Python3 ready.  Django, since v2.0
is now 3.0 only.

-tkc






-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Chris Warrick]

On 22 October 2017 at 13:48, Chris Angelico  wrote:
> On Sun, Oct 22, 2017 at 10:34 PM, Chris Warrick  wrote:
>> On 22 October 2017 at 13:25, Lele Gaifax  wrote:
>>> Chris Warrick  writes:
>>>
 Zope is effectively dead these days.
>>>
>>> Except it's alive and kicking: https://blog.gocept.com/
>>>
>>> :-)
>>>
>>> ciao, lele.
>>
>> A few people still care, sure. But how alive is a project with 16
>> (sixteen) people on IRC (freenode #zope), 85 (eighty-five) stars on
>> GitHub, and 205 issues on GitHub (since 2013)?
>>
>
> I'm not too bothered by number of stars, nor necessarily by the issue
> count (maybe a lot of their work is discussed by email, not the
> tracker). Most important, to me, is the number of commits. And that
> doesn't look too bad; there aren't a huge number of them, but they're
> fairly consistently being made. So I'd say the project isn't dead,
> though you could very well argue that it's merely playing catch-up. (I
> didn't look at the content of the commits in detail or anything.)
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list

Mailing lists are quiet as well:
https://mail.zope.org/pipermail/zope/
https://mail.zope.org/pipermail/zope-dev/

For a web framework, the daily commit count is much less important
than the size of the active community. An active community means more
people that can offer support, fix bugs, write docs, provide
ready-made modules to achieve common tasks. Zope’s community is
nonexistent. Django has 1483 contributors and 29k stars on GitHub.
Zope has 83 and 85 respectively.

https://blog.gocept.com/2016/10/04/zope-resurrection-part-2-defibrillation/

> Zope is not dead. On the sprint there were nearly 20 people who use Zope for 
> their daily work.

Oh my, twenty people! That’s a lot! A lot!

Yeah, no. Zope is dead. With a few folks going through the “denial”
phase. Or the “I’ve got legacy code from last decade I can’t be
bothered to rewrite” phase.

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Chris Angelico]

On Sun, Oct 22, 2017 at 10:34 PM, Chris Warrick  wrote:
> On 22 October 2017 at 13:25, Lele Gaifax  wrote:
>> Chris Warrick  writes:
>>
>>> Zope is effectively dead these days.
>>
>> Except it's alive and kicking: https://blog.gocept.com/
>>
>> :-)
>>
>> ciao, lele.
>
> A few people still care, sure. But how alive is a project with 16
> (sixteen) people on IRC (freenode #zope), 85 (eighty-five) stars on
> GitHub, and 205 issues on GitHub (since 2013)?
>

I'm not too bothered by number of stars, nor necessarily by the issue
count (maybe a lot of their work is discussed by email, not the
tracker). Most important, to me, is the number of commits. And that
doesn't look too bad; there aren't a huge number of them, but they're
fairly consistently being made. So I'd say the project isn't dead,
though you could very well argue that it's merely playing catch-up. (I
didn't look at the content of the commits in detail or anything.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Chris Warrick]

On 22 October 2017 at 13:25, Lele Gaifax  wrote:
> Chris Warrick  writes:
>
>> Zope is effectively dead these days.
>
> Except it's alive and kicking: https://blog.gocept.com/
>
> :-)
>
> ciao, lele.

A few people still care, sure. But how alive is a project with 16
(sixteen) people on IRC (freenode #zope), 85 (eighty-five) stars on
GitHub, and 205 issues on GitHub (since 2013)?

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Lele Gaifax]

Chris Warrick  writes:

> Zope is effectively dead these days.

Except it's alive and kicking: https://blog.gocept.com/

:-)

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Chris Warrick]

On 22 October 2017 at 12:24, Patrick Vrijlandt  wrote:
> Hello list,
>
> I would like your recommendation on the choice of a web framework.
>
> The project is completely new, there are no histories to take into account
> (current solutions are paper-based). The website involves questionnaires
> that will be developed, filled out and stored. Users are not programmers or
> developers. They should be authenticated. Version control is required.
> Internationalization is not an issue. I expect that the project will add
> additional requirements and complexity later on that I can not foresee yet.
> I'm targeting a single deployment (maybe a second on a development machine).
> I usually work on Windows, but Linux can be considered.

If you intend to put this on a server, and you probably do since
you’re talking about web frameworks, a Linux machine is your best bet
for that. Windows isn’t a good platform for making web servers out of.
(Your development machine can probably run Windows.)

> I'm not afraid to learn a (=one) new framework (that would actually be fun)
> but trying out a lot of them is not feasible. My current goal is a
> demonstration version of the project as a proof of concept. I may want to
> hand it over to a commercial solution at that stage.
>
> I'm an experienced python programmer but not an experienced web developer. A
> few years ago I read some books about Zope and Plone, but never did serious
> development with those. I currently maintain an intranet site in MoinMoin. I
> assume Zope could still be a potential choice, but it may have lost the
> vibrancy of a few years ago. Also, I would not know which version to choose
> (Zope 4, BlueBream, or something like Grok). The problem seems too
> complicated for micro frameworks like bottle of Flask. Django could be the
> next alternative.

Zope is effectively dead these days. IMO your best bet would be Django:

* built-in database support
* built-in user authentication support
* built-in administrator panel
* i18n support available for when you need it
* it’s a modern, friendly web framework

If you went with Flask, you’d end up with a pile of plugins (for auth,
for databases, for other things) and reimplement half of Django,
badly.

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: choice of web-framework

[Chris Angelico]

On Sun, Oct 22, 2017 at 9:24 PM, Patrick Vrijlandt  wrote:
> Hello list,
>
> I would like your recommendation on the choice of a web framework.
>
> The project is completely new, there are no histories to take into account
> (current solutions are paper-based). The website involves questionnaires
> that will be developed, filled out and stored. Users are not programmers or
> developers. They should be authenticated. Version control is required.
> Internationalization is not an issue. I expect that the project will add
> additional requirements and complexity later on that I can not foresee yet.
> I'm targeting a single deployment (maybe a second on a development machine).
> I usually work on Windows, but Linux can be considered.
>
> I'm not afraid to learn a (=one) new framework (that would actually be fun)
> but trying out a lot of them is not feasible. My current goal is a
> demonstration version of the project as a proof of concept. I may want to
> hand it over to a commercial solution at that stage.
>
> I'm an experienced python programmer but not an experienced web developer. A
> few years ago I read some books about Zope and Plone, but never did serious
> development with those. I currently maintain an intranet site in MoinMoin. I
> assume Zope could still be a potential choice, but it may have lost the
> vibrancy of a few years ago. Also, I would not know which version to choose
> (Zope 4, BlueBream, or something like Grok). The problem seems too
> complicated for micro frameworks like bottle of Flask. Django could be the
> next alternative.
>
> Finally, for a new project, I would not like to be confined to Python 2.7.
>
> What are your ideas?

First off, a huge thank-you for laying out your requirements in such detail!

My personal choice, under the circumstances, would be Flask. Your
project isn't too complicated for it, and it's not too hard to learn
(I learned it in a weekend, though YMMV of course). Authentication is
a fully-supported plugin (flask-login). I'm not sure what you mean by
"version control" - of course your actual Python code can be managed
in git/hg, but if it's a project requirement that your *data* be
git-managed too, then you'll need to plan something out for that. Not
too hard though.

Python 3 is fully supported by Flask, so that's not a problem. Windows
and Linux are also both viable platforms. I strongly recommend
creating a file "requirements.txt" in your project root and recording
every package you use there, so you can just run "pip install -r
requirements.txt" to grab everything. Using a virtual environment
("python3 -m venv env" in recent-enough Pythons) can help to keep your
dependencies clean. If you do that from the start of the project, and
avoid using anything that's Windows-specific, you shouldn't have much
trouble changing OSes.

For the database, I generally use PostgreSQL, unless the job's so
simple it can be done with flat files. Using Flask with SQLAlchemy is
a popular option, but you can also dive into psycopg2 directly (the
"2" doesn't mean "Python 2.7 only", it's fine). The tech stack
Python+Flask+SQLAlchemy+PostgreSQL+Linux is an extremely solid one, or
you can switch out any part fairly easily.

Disclaimer: I use Flask and SQLAlchemy when I'm teaching my students
how to build web apps in Python, but I don't have much experience with
any other frameworks or ORMs. Other options may very well be viable
and/or superior; all I can say is that the above *is* viable.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list