Re: [osx] dyld: Library not loaded: /usr/local/Cellar/python@3.8/3.8.3_1/Frameworks/Python.framework/Versions/3.8/Python

[Mats Wichmann]

On 12/4/20 7:15 AM, Noah wrote:

Hi there,

Anybody know how to fix this issue on a mac?

❯ /usr/local/bin/python
dyld: Library not loaded: 
/usr/local/Cellar/python@3.8/3.8.3_1/Frameworks/Python.framework/Versions/3.8/Python 


   Referenced from: /usr/local/bin/python
   Reason: image not found
[1]    32209 abort  /usr/local/bin/python


Looks like you're using Python installed via Homebrew ('Cellar' being 
the hint), perhaps hit up that project for ideas?  It looks like the 
install is inconsistent somehow.



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

[osx] dyld: Library not loaded: /usr/local/Cellar/python@3.8/3.8.3_1/Frameworks/Python.framework/Versions/3.8/Python

[Noah]

Hi there,

Anybody know how to fix this issue on a mac?

❯ /usr/local/bin/python
dyld: Library not loaded: 
/usr/local/Cellar/python@3.8/3.8.3_1/Frameworks/Python.framework/Versions/3.8/Python

  Referenced from: /usr/local/bin/python
  Reason: image not found
[1]32209 abort  /usr/local/bin/python

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

A nice collection of often useful awesome Python frameworks

[heshanfu]

A nice collection of often useful awesome Python frameworks, libraries and 
software.

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

Re: Web Frameworks

[Patrick McFarling]

On Thursday, 9 March 2017 05:05:37 UTC-5, David Froger  wrote:
> There is a free ebook on the subject on O'Reilly:
> http://www.oreilly.com/web-platform/free/python-web-frameworks.csp
> 
> Hope it helps,
> David
> 
> 
> Quoting Patrick McFarling (2017-03-09 10:24:16)
> > I would like to know what are the pros and cons of the web frameworks made 
> > in python.
> > The one I tend to lean towards is Flask.
> > -- 
> > https://mail.python.org/mailman/listinfo/python-list

Thanks for the book!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks

[David Froger]

There is a free ebook on the subject on O'Reilly:
http://www.oreilly.com/web-platform/free/python-web-frameworks.csp

Hope it helps,
David


Quoting Patrick McFarling (2017-03-09 10:24:16)
> I would like to know what are the pros and cons of the web frameworks made in 
> python.
> The one I tend to lean towards is Flask.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Web Frameworks

[Patrick McFarling]

I would like to know what are the pros and cons of the web frameworks made in 
python.
The one I tend to lean towards is Flask.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python dashboard tutorials/frameworks for interactive, D3.js graphs in IPython Notebooks

[Chris Angelico]

On Fri, Nov 6, 2015 at 5:13 PM,   wrote:
> On Thursday, July 9, 2015 at 8:10:16 PM UTC-4, Matt Sundquist wrote:
>> For more background, refer to our Python docs: https://plot.ly/python/, our 
>> Python framework for making dashboards: https://github.com/plotly/dash, our 
>> data science blog: http://moderndata.plot.ly/, or these 21 IPython 
>> Notebooks: https://plot.ly/python/ipython-notebooks/.
>>
>
> You guys are so expensive - not even worth looking into your product. 
> Absolutely retarded.
> Srinath

No need to be so rude as you complain about people getting paid for their work.

I'm not even sure your complaint is accurate; where did you see
ridiculously high prices? I started with the first link I quoted above
(the Python docs), and up the top is this note: "plotly is free for
unlimited public use". Then there's a zero-dollar option (though that
might be the same as the previous note), and a $20/mo option called
"professional". If professional usage is only $20 per month, I don't
think it's fair to call it "absolutely retarded". Yes, there's also an
on-premise option for ten grand a year, but that's some serious
top-end privacy stuff... if you think you have to pay that just to
make use of their services, then yes, I can see that you'd complain
about the pricing!

Or was this a deliberate troll to make people go look at the pricing
in more detail?

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

Re: Python dashboard tutorials/frameworks for interactive, D3.js graphs in IPython Notebooks

[srinath . nathan]

On Thursday, July 9, 2015 at 8:10:16 PM UTC-4, Matt Sundquist wrote:
> Hi all,
> 
> I'm part of Plotly, and we've just finished a few releases I thought I'd pass 
> along. 
> 
> These tools make it easy to craft interactive graphs and dashboards with 
> D3.js using Python. We're especially drawn towards matplotlib, pandas, and 
> IPython. We're still early in building, so any and all feedback and help is 
> much appreciated.
> 
> First, here is an overview of some of our dashboard capabilities:
> 
> http://blog.plot.ly/post/123617968702/online-dashboards-eight-helpful-tips-you-should
> 
> For more background, refer to our Python docs: https://plot.ly/python/, our 
> Python framework for making dashboards: https://github.com/plotly/dash, our 
> data science blog: http://moderndata.plot.ly/, or these 21 IPython Notebooks: 
> https://plot.ly/python/ipython-notebooks/.
> 
> Feedback and suggestions are welcome!
> 
> M

You guys are so expensive - not even worth looking into your product. 
Absolutely retarded.
Srinath
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How may I learn Python Web Frameworks

[Nonami Animashaun]

The official Django docs is pretty detailed
https://docs.djangoproject.com/en/1.8/

You could also look at the Django book but it confesses to being written
for version 1.4 even though it goes ahead to assure us that it's not
outdated
https://django-book.readthedocs.org/en/latest/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How may I learn Python Web Frameworks

[darnold via Python-list]

you'll find a very extensive Flask tutorial at 
http://blog.miguelgrinberg.com/post/the-flask-mega-tutorial-part-i-hello-world .
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How may I learn Python Web Frameworks

[Laura Creighton]

web2py http://www.web2py.com/
has extensive tutorials, videos, and a book.

Laura

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

How may I learn Python Web Frameworks

[subhabrata . banerji]

Dear Group,

I am slightly new in Python Web Frameworks. I could learn bit of Django, Flask 
and Bottle. 
But I am looking for a good web based tutorial like Python or NLTK. 
Somehow, I did not find documentations for web frameworks are very good, one 
has to do lot of experiments even to learn basic things.
 
I am looking for a good book like Dive into Python or some good web based 
tutorials. 

I tried to search but unfortunately could not find. 

I am using Python2.7+ on Windows 7. 

If any one of the members may kindly suggest.

Regards,
Subhabrata Banerjee. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Python dashboard tutorials/frameworks for interactive, D3.js graphs in IPython Notebooks

[Matt Sundquist]

Hi all,

I'm part of Plotly, and we've just finished a few releases I thought I'd pass 
along. 

These tools make it easy to craft interactive graphs and dashboards with D3.js 
using Python. We're especially drawn towards matplotlib, pandas, and IPython. 
We're still early in building, so any and all feedback and help is much 
appreciated.

First, here is an overview of some of our dashboard capabilities:

http://blog.plot.ly/post/123617968702/online-dashboards-eight-helpful-tips-you-should

For more background, refer to our Python docs: https://plot.ly/python/, our 
Python framework for making dashboards: https://github.com/plotly/dash, our 
data science blog: http://moderndata.plot.ly/, or these 21 IPython Notebooks: 
https://plot.ly/python/ipython-notebooks/.

Feedback and suggestions are welcome!

M


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

Re: [GUI] Good frameworks for Windows/Mac?

[Gilles]

On Thu, 8 Aug 2013 01:47:21 -0700 (PDT), sagar varule
 wrote:
>Pyside is also Good. It has a Designer which can be helpful.

Thanks for the info.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [GUI] Good frameworks for Windows/Mac?

[sagar varule]

On Tuesday, August 6, 2013 4:05:40 PM UTC+5:30, Gilles wrote:
> Hello
> 
> 
> 
> I need to write a small GUI application that should run on Windows and
> 
> Mac.
> 
> 
> 
> What open-source framework would you recommend? I just need basic
> 
> widgets (button, listbox, etc.) and would rather a solution that can
> 
> get me up and running fast.
> 
> 
> 
> I know about wxWidgets and Qt: Are there other good options I should
> 
> know about?
> 
> 
> 
> Thank you.

Pyside is also Good. It has a Designer which can be helpful.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [GUI] Good frameworks for Windows/Mac?

[Gilles]

On Tue, 6 Aug 2013 13:22:01 +0200, Vlastimil Brom
 wrote:
>I mostly use wxPython myself, but if you just need some basic widgets
>and not some very complex or non-standard layouts, the tkinter -
>available in the standard library - might be perfectly viable.
>http://docs.python.org/3.3/library/tk.html
>The more recent versions of python also support ttk and Tix which has
>further possibilities, styling etc.
>There is further e.g. Python GUI
>http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/
>
>and several others
>http://wiki.python.org/moin/GuiProgramming

Thanks for the links. I'll play with Tkinter, and if it's not good
enough, check the alternatives.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [GUI] Good frameworks for Windows/Mac?

[Jordi Riera]

Hey

you can build GUIs with tkinter . Easy
but not as powerful than PyQt can be.
I think it is os agnostic.

Regards,
Jordi


On Tue, Aug 6, 2013 at 12:35 PM, Gilles  wrote:

> Hello
>
> I need to write a small GUI application that should run on Windows and
> Mac.
>
> What open-source framework would you recommend? I just need basic
> widgets (button, listbox, etc.) and would rather a solution that can
> get me up and running fast.
>
> I know about wxWidgets and Qt: Are there other good options I should
> know about?
>
> Thank you.
> --
> http://mail.python.org/mailman/listinfo/python-list
>



-- 
- Jordi Riera, Connecting people.
+33 662217507
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [GUI] Good frameworks for Windows/Mac?

[Vlastimil Brom]

2013/8/6 Gilles :
> Hello
>
> I need to write a small GUI application that should run on Windows and
> Mac.
>
> What open-source framework would you recommend? I just need basic
> widgets (button, listbox, etc.) and would rather a solution that can
> get me up and running fast.
>
> I know about wxWidgets and Qt: Are there other good options I should
> know about?
>
> Thank you.
> --
> http://mail.python.org/mailman/listinfo/python-list

Hi,
I mostly use wxPython myself, but if you just need some basic widgets
and not some very complex or non-standard layouts, the tkinter -
available in the standard library - might be perfectly viable.
http://docs.python.org/3.3/library/tk.html
The more recent versions of python also support ttk and Tix which has
further possibilities, styling etc.
There is further e.g. Python GUI
http://www.cosc.canterbury.ac.nz/greg.ewing/python_gui/

and several others
http://wiki.python.org/moin/GuiProgramming

hth,
  vbr
-- 
http://mail.python.org/mailman/listinfo/python-list

[GUI] Good frameworks for Windows/Mac?

[Gilles]

Hello

I need to write a small GUI application that should run on Windows and
Mac.

What open-source framework would you recommend? I just need basic
widgets (button, listbox, etc.) and would rather a solution that can
get me up and running fast.

I know about wxWidgets and Qt: Are there other good options I should
know about?

Thank you.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Installation on Mac OSX 10.6.8 doesn't create the folder: /System/Library/Frameworks/Python.framework/Versions/2.7/

[Ned Deily]

In article 
,
 Jason Swails  wrote:

> On Tue, Apr 2, 2013 at 6:22 AM, kramer65  wrote:
> 
> > Hello people,
> >
> >
> > I installed python 2.7 on Mac OSX 10.6.8 with no problems  and it is
> > working fine. When I try to install Kivy however (www.kivy.org), I get an
> > error saying:
> >
> 
> How did you install Python 2.7?  How did you install Kivy?  Note that Kivy
> states 10.7 or 10.8 is required.

> 
> /> /usr/local/bin/kivy: line 24: 
> > /System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7: No 
> > such file or directory
> > /usr/local/bin/kivy: line 24: exec: 
> > /System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7: 
> > cannot execute: No such file or directory
> > 
> > Upon inspection the there are folders named 2.3, 2.5 and 2.6 in the 
> > Versions 
> > folder, but indeed no folder named "2.7". When I log into the interactive 
> > python command line however, it clearly says I've got python 2.7.3 
> > installed.

/System/Library/Frameworks is the location for Apple-supplied system 
Pythons.  OS X 10.6 ships with complete versions of Python 2.6 and 2.5 
(and the shared libs for 2.3).  So you won't find a 2.7 folder there in 
10.6.8.  In OS X 10.7 and 10.8, Apple ships 2.7, 2.6, and 2.5.

If you used one of the python.org installers to install 2.7, it will be 
installed into /Library/Frameworks and, by default, symlinks will be 
installed in /usr/local/bin for python, python2.7, etc.  Since 
/usr/local/bin/kivy appears to be a script of some sort, examine it and 
see exactly what command is on line 24.  The solution might be as simple 
as editing a line there to remove the "/System" part.

> Another option is to grok the MacPorts Portfile for Python 2.7 to figure
> out how they compile it using the Mac Framework and emulate that process
> when you build Python 2.7 from source (but don't install to /opt/local).

I'm not sure what you are proposing there.  But you should never attempt 
to install anything into /System/Library: that's part of OS X and 
controlled by Apple.

-- 
 Ned Deily,
 n...@acm.org

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

Re: Installation on Mac OSX 10.6.8 doesn't create the folder: /System/Library/Frameworks/Python.framework/Versions/2.7/

[Jason Swails]

On Tue, Apr 2, 2013 at 6:22 AM, kramer65  wrote:

> Hello people,
>
>
> I installed python 2.7 on Mac OSX 10.6.8 with no problems  and it is
> working fine. When I try to install Kivy however (www.kivy.org), I get an
> error saying:
>

How did you install Python 2.7?  How did you install Kivy?  Note that Kivy
states 10.7 or 10.8 is required.

My suggestion is to use MacPorts to build Python 2.7 (or something similar,
like HomeBrew or Fink), then build Kivy from source, rather than using the
Mac installer.  The Mac installer for Kivy would be reasonable in expecting
Python 2.7 to be installed in the standard Frameworks directory since it
requires Python 2.7.

Another option is to grok the MacPorts Portfile for Python 2.7 to figure
out how they compile it using the Mac Framework and emulate that process
when you build Python 2.7 from source (but don't install to /opt/local).

If all else fails, upgrade to 10.7 ;).

Good luck,
Jason
-- 
http://mail.python.org/mailman/listinfo/python-list

Installation on Mac OSX 10.6.8 doesn't create the folder: /System/Library/Frameworks/Python.framework/Versions/2.7/

[kramer65]

Hello people,


I installed python 2.7 on Mac OSX 10.6.8 with no problems  and it is working 
fine. When I try to install Kivy however (www.kivy.org), I get an error saying:

/usr/local/bin/kivy: line 24: 
/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7: No such 
file or directory
/usr/local/bin/kivy: line 24: exec: 
/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7: cannot 
execute: No such file or directory

Upon inspection the there are folders named 2.3, 2.5 and 2.6 in the Versions 
folder, but indeed no folder named "2.7". When I log into the interactive 
python command line however, it clearly says I've got python 2.7.3 installed.

Does anybody know what the problem might be here?


Kind regards,
kramer
-- 
http://mail.python.org/mailman/listinfo/python-list

Are there any Python libraries/frameworks which generate AngularJS?

[Alec Taylor]

I find the stateless SOA architecture to be increasingly useful and relevant.

For example, it allows you to write once; deploy to:
- Website (for viewing in web browsers)
- Native mobile apps (using Adobe PhoneGap or similar)
- Ubuntu apps
- Windows Metro Store apps (for Windows 8)

Unfortunately this design has a major drawback; slower development time. Using 
any ORM and an associated form generator, one can develop their web application 
very quickly.

Are there any ORM form generators for Python which can translate Models to 
AngularJS forms?

[including CSRF token and RESTful setup; with JSON as format]

Thanks for all suggestions,

Alec Taylor

BTW: Also posted this on stackoverflow - http://stackoverflow.com/q/15513907

PS: I currently use the web2py framework; but this is an important enough 
feature that I am willing to switch to ANY other Python web-framework…
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Testing Frameworks

[John Gordon]

In  Greg Lindstrom 
 writes:

> I'm not wanting to start anything here, but I am wanting to automate
> testing of my Django-based websites.  A quick search on Google turns up a

Have you looked at using the built-in django test client?

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

Web Testing Frameworks

[Greg Lindstrom]

Hello,

I'm not wanting to start anything here, but I am wanting to automate
testing of my Django-based websites.  A quick search on Google turns up a
number of packages and I would like to know if any stand out from the
others?  Our main sites are used to display a customer dashboard, so my
concerns are is the site up and assessable, are the proper navigational
tabs displayed and is the appropriate information presented when I fill out
a request.  My guess is that is pretty standard for testing a web site?

So,

1.  What framework(s) should I look at?
2.  Where can I get information/documentation/training on how to test a web
site?

Thanks!
--greg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Thomas Bach]

On Wed, Nov 21, 2012 at 12:49:52PM -0800, rh wrote:
> 
> wheezy + "myvirtualenv" = 3.3MB
> pyramid = 92MB

$ mkvirtualenv --no-site-packages -p python2.7 pyramid
$ pip install -U distribute
$ pip install pyramid
$ du -h .virtualenvs/pyramid 
22M .virtualenvs/pyramid
$ du -s .virtualenvs/pyramid/lib/python2.7/site-packages/* | sort -n | tail -n 
5 
728 .virtualenvs/pyramid/lib/python2.7/site-packages/pip-1.1-py2.7.egg
1556.virtualenvs/pyramid/lib/python2.7/site-packages/setuptools
1724.virtualenvs/pyramid/lib/python2.7/site-packages/zope
2044.virtualenvs/pyramid/lib/python2.7/site-packages/chameleon
6312.virtualenvs/pyramid/lib/python2.7/site-packages/pyramid

I think 22 MB are OK given the functionality Pyramid has to offer.

Just my 2 cents,
 Thomas.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Modulok]

> On Wed, Nov 21, 2012 at 10:43 PM, Steven D'Aprano
>  wrote:
>> On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
>>
>>> Counting complexity by giving a score to every statement encourages code
>>> like this:
>>>
>>> def bletch(x,y):
>>>   return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
>>>
>>> instead of:
>>>
>>> def bletch(x,y):
>>>   if mode=="foo": return x+y*2
>>>   if mode=="bar": return x*4+y
>>>   if mode=="quux": return x+math.sin(y) return x
>>>
>>> Okay, this is a stupid contrived example, but tell me which of those
>>> you'd rather work with
>>
>>

> Oh, I'm *so* glad I work in a small company.

Agreed. Do we rate a contractor's quality of workmanship and efficiency by the
number of nails he drives?

Of course not. That would be ridiculous.

A better metric of code quality and complexity would be to borrow from science
and mathematics. i.e. a peer review or audit by others working on the project
or in the same field of study. Unfortunately this isn't cheap or easily
computed and doesn't translate nicely to a bar graph.

Such is reality.
-Modulok-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Chris Angelico]

On Wed, Nov 21, 2012 at 10:43 PM, Steven D'Aprano
 wrote:
> On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
>
>> Counting complexity by giving a score to every statement encourages code
>> like this:
>>
>> def bletch(x,y):
>>   return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
>>
>> instead of:
>>
>> def bletch(x,y):
>>   if mode=="foo": return x+y*2
>>   if mode=="bar": return x*4+y
>>   if mode=="quux": return x+math.sin(y) return x
>>
>> Okay, this is a stupid contrived example, but tell me which of those
>> you'd rather work with
>
>
> Am I being paid by the hour or the line?

You're on a salary, but management specified some kind of code metrics
as a means of recognizing which of their programmers are more
productive, and thus who gets promoted.

Oh, I'm *so* glad I work in a small company. We've only had one
programmer that we "let go" (and actually, it was literally letting
him go - he said he was no good, hoping that we'd beg him to stay, and
we simply didn't beg him to stay), and the metric of code quality was
simply that both my boss and I looked at his code and said that it
wasn't good enough. Much simpler. (Though my boss and I have differing
views on how many lines of code some things should be. We end up
having some rather amusing debates about trivial things like line
breaks.)

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

Re: Web Frameworks Excessive Complexity

[Chris Rebert]

On Wed, Nov 21, 2012 at 10:57 AM, rh  wrote:
> On Wed, 21 Nov 2012 10:12:26 -0800
> Chris Rebert  wrote:
>> On Wed, Nov 21, 2012 at 9:49 AM, rh 
>> wrote:
>> > On Tue, 20 Nov 2012 20:41:42 +0300
>> > Andriy Kornatskyy  wrote:

>> > I'm looking at different technology right now on which to base a
>> > site. I tried pyramid and after install it consumed 92MB of disk.
>> > It seemed large and it turns out that it installed its own version
>> > of python. Seems more complex to me, yet another python on disk.
>>
>> That's how virtualenvs (http://www.virtualenv.org/ ) normally work.
>> Not really Pyramid's fault, it's more a deficiency of the current
>> Python package management tools.
>
> There's still 92MB under pyramid, I just installed a new virtualenv and
> installed wheezy.web, grand total 3.3MB.
>
> What deficiency?

"install[ing] its own version of python"

-- Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

Richard,

Thank you for the comment.

I have examined web frameworks for PEP8 and CC metrics already. Results are 
here:
http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html
http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html

Same applies to performance benchmarks:
http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html
http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html
http://mindref.blogspot.com/2012/10/python-web-reverse-urls-benchmark.html
http://mindref.blogspot.com/2012/10/python-web-caching-benchmark.html

and template engine related:
http://mindref.blogspot.com/2012/10/python-templates-benchmark.html
http://mindref.blogspot.com/2012/07/python-fastest-template.html

If there are any other metrics we can gather automatically I will be happy to 
run them.

Thank you for your interest of wheezy.web. Before you buy:

Demo application source:
https://bitbucket.org/akorn/wheezy.web/src/tip/demos/template
Demo application live:
http://wheezy.pythonanywhere.com/

Tutorial:
http://packages.python.org/wheezy.web/tutorial.html
Finished:
https://bitbucket.org/akorn/wheezy.web/src/tip/demos/guestbook

Try understand what is cache dependency and how you benefit of using it with 
content caching. Try relate it with web caching benchmark from above and 
imagine 99% of your web application content is served out from cache, even it 
is dynamic (you control content cache with cache dependency).

Thanks.

Andriy Kornatskyy


> To: python-list@python.org
> From: richard_hubb...@lavabit.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 09:49:39 -0800
>
> On Tue, 20 Nov 2012 20:41:42 +0300
> Andriy Kornatskyy  wrote:
>
> >
> > Cyclomatic (or conditional) complexity is a metric used to indicate
> > the complexity of a source code. Excessive complexity is something
> > that is beyond recommended level of 10 (threshold that points to the
> > fact the source code is too complex and refactoring is suggested).
> > Here is a list of web frameworks examined: bottle, cherrypy,
> > circuits, django, flask, pyramid, pysi, tornado, turbogears, web.py,
> > web2py and wheezy.web.
> >
> > You can read more here:
> >
> > http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html
>
> You are the author of wheezy.web right? Can't blame you for trying to
> market your product. The conclusions, or lack of, are meaningless to me.
> I have to get in and drive the car before I go all in and buy it.
>
> I'm looking at different technology right now on which to base a site.
> I tried pyramid and after install it consumed 92MB of disk. It seemed
> large and it turns out that it installed its own version of python.
> Seems more complex to me, yet another python on disk.
>
> Anyway if you're really serious about making a point that complexity
> matters you'll have to measure many more things than loc or cc.
>
> Did you look at the number of commits to the same file over time?
> Etc. Number of authors for same file? Etc., etc. Number of security
> fixes? There must be a correlation between complexity and insecurity.
> Maybe check for randomness of the code. Not sure how, maybe
> look for strange, non-idiomatic uses of the language.
>
> I'm no computer scientist and I'm sure there are volumes on all this.
>
> Then there's also the social side, how much discussion takes place
> about the software? Does more discussion mean more problems?
> More project vibrancy? You could check for vocab, etc.
>
> I'm gonna take a look at wheezy.web.
> >
> > Thanks.
> >
> > Comments or suggestions are welcome.
> >
> > Andriy Kornatskyy
> >
>
>
> --
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Chris Rebert]

On Wed, Nov 21, 2012 at 9:49 AM, rh  wrote:
> On Tue, 20 Nov 2012 20:41:42 +0300
> Andriy Kornatskyy  wrote:
>> Cyclomatic (or conditional) complexity is a metric used to indicate
>> the complexity of a source code. Excessive complexity is something
>> that is beyond recommended level of 10 (threshold that points to the
>> fact the source code is too complex and refactoring is suggested).
>> Here is a list of web frameworks examined: bottle, cherrypy,
>> circuits, django, flask, pyramid, pysi, tornado, turbogears, web.py,
>> web2py and wheezy.web.
>>
>> You can read more here:
>>
>> http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html
>
> You are the author of wheezy.web right? Can't blame you for trying to
> market your product. The conclusions, or lack of, are meaningless to me.
> I have to get in and drive the car before I go all in and buy it.
>
> I'm looking at different technology right now on which to base a site.
> I tried pyramid and after install it consumed 92MB of disk. It seemed
> large and it turns out that it installed its own version of python.
> Seems more complex to me, yet another python on disk.

That's how virtualenvs (http://www.virtualenv.org/ ) normally work.
Not really Pyramid's fault, it's more a deficiency of the current
Python package management tools.

Cheers,
Chris
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Robert Kern]

On 21/11/2012 12:47, Andriy Kornatskyy wrote:


Hm... what serves an evidence purpose for you?


Well-done empirical studies, like the one I gave you.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

Hm... what serves an evidence purpose for you?

See functions at line 2619 and 2974 as an example for CC 20+:
https://github.com/defnull/bottle/blob/master/bottle.py

Andriy



> To: python-list@python.org
> From: robert.k...@gmail.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 12:26:26 +
>
> On 21/11/2012 12:17, Andriy Kornatskyy wrote:
> >
> > Agreed. I think we have pretty much the same point of view on this.
> >
> > All these metrics advise you... this is again depends how you look at this. 
> > If you are a new comer to a project, you usually spend some time on code 
> > review, talk to people, read docs if any. The qa tools for static code 
> > analysis give you an initial picture, how it fits with your own vision, 
> > etc. Convince or accept?
>
> No, we don't have the same point of view on this. I think that using metrics
> that have no evidence for their utility is a misleading distraction.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
> that is made terrible by our own mad attempt to interpret it as though it had
> an underlying truth."
> -- Umberto Eco
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Robert Kern]

On 21/11/2012 12:17, Andriy Kornatskyy wrote:


Agreed. I think we have pretty much the same point of view on this.

All these metrics advise you... this is again depends how you look at this. If 
you are a new comer to a project, you usually spend some time on code review, 
talk to people, read docs if any. The qa tools for static code analysis give 
you an initial picture, how it fits with your own vision, etc. Convince or 
accept?


No, we don't have the same point of view on this. I think that using metrics 
that have no evidence for their utility is a misleading distraction.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

Agreed. I think we have pretty much the same point of view on this.

All these metrics advise you... this is again depends how you look at this. If 
you are a new comer to a project, you usually spend some time on code review, 
talk to people, read docs if any. The qa tools for static code analysis give 
you an initial picture, how it fits with your own vision, etc. Convince or 
accept?

Andriy Kornatskyy



> To: python-list@python.org
> From: robert.k...@gmail.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 11:54:06 +
>
> On 21/11/2012 11:02, Andriy Kornatskyy wrote:
> >
> > Robert,
> >
> > You would never get a better product by accident.
> >
> > The meaning of better product might differ from team to team but you can 
> > not ignore excessive complexity. Earlier or later you get back to that code 
> > and refactor it, thus existence of such fact was driven by your intention 
> > to make it a bit better (easier to understand, to support, to cover with 
> > unit tests, etc), with a team of 20 heads you can get even further: the 
> > whole team adherence. So those drops make the overall picture better. This 
> > is what you, as a software developer, donate to what the final better 
> > product become.
>
> I think you may be misinterpreting the English idiom. I don't mean that your
> finger slips and randomly types out better code. I mean that by focusing on CC
> as a metric for improvement, you may very well end up improving the code, but
> it's not because you reduced the CC of the code. It's because of all of those
> *other* things that you talk about. Those are the things that should drive 
> your
> refactoring, not CC, because they actually do cause improved code.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
> that is made terrible by our own mad attempt to interpret it as though it had
> an underlying truth."
> -- Umberto Eco
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Robert Kern]

On 21/11/2012 11:02, Andriy Kornatskyy wrote:


Robert,

You would never get a better product by accident.

The meaning of better product might differ from team to team but you can not 
ignore excessive complexity. Earlier or later you get back to that code and 
refactor it, thus existence of such fact was driven by your intention to make 
it a bit better (easier to understand, to support, to cover with unit tests, 
etc), with a team of 20 heads you can get even further: the whole team 
adherence. So those drops make the overall picture better. This is what you, as 
a software developer, donate to what the final better product become.


I think you may be misinterpreting the English idiom. I don't mean that your 
finger slips and randomly types out better code. I mean that by focusing on CC 
as a metric for improvement, you may very well end up improving the code, but 
it's not because you reduced the CC of the code. It's because of all of those 
*other* things that you talk about. Those are the things that should drive your 
refactoring, not CC, because they actually do cause improved code.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

I believe for the quality of code you produce.

Thanks.

Andriy



> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 11:43:10 +
> To: python-list@python.org
>
> On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:
>
> > Counting complexity by giving a score to every statement encourages code
> > like this:
> >
> > def bletch(x,y):
> > return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
> >
> > instead of:
> >
> > def bletch(x,y):
> > if mode=="foo": return x+y*2
> > if mode=="bar": return x*4+y
> > if mode=="quux": return x+math.sin(y) return x
> >
> > Okay, this is a stupid contrived example, but tell me which of those
> > you'd rather work with
>
>
> Am I being paid by the hour or the line?
>
>
>
>
> --
> Steven
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Robert Kern]

On 21/11/2012 01:43, Steven D'Aprano wrote:

On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote:


The source of bugs is not excessive complexity in a method, just
excessive lines of code.


Taken literally, that cannot possibly the case.

def method(self, a, b, c):
 do_this(a)
 do_that(b)
 do_something_else(c)


def method(self, a, b, c):
 do_this(a); do_that(b); do_something_else(c)


It *simply isn't credible* that version 1 is statistically likely to have
twice as many bugs as version 2. Over-reliance on LOC is easily gamed,
especially in semicolon languages.


Logical LoC (executable LoC, number of statements, etc.) is a better measure 
than Physical LoC, I agree. That's not the same thing as cyclomatic complexity, 
though. Also, the relationship between LoC (of either type) and bugs is not 
linear (at least not in the small-LoC regime), so you are certainly correct that 
it isn't credible that version 1 is likely to have twice as many bugs as version 
2. No one is saying that it is.



Besides, I think you have the cause and effect backwards. I would rather
say:

The source of bugs is not lines of code in a method, but excessive
complexity. It merely happens that counting complexity is hard, counting
lines of code is easy, and the two are strongly correlated, so why count
complexity when you can just count lines of code?


No, that is not the takeaway of the research. More code correlates with more 
bugs. More cyclomatic complexity also correlates with more bugs. You want to 
find out what causes bugs. What the research shows is that cyclomatic complexity 
is so correlated with LoC that it is going to be very difficult, or impossible, 
to establish a causal relationship between cyclomatic complexity and bugs. The 
previous research that just correlated cyclomatic complexity to bugs without 
controlling for LoC does not establish the causal relationship.



Keep in mind that something like 70-80% of published scientific papers
are never replicated, or cannot be replicated. Just because one paper
concludes that LOC alone is a better metric than CC doesn't necessary
make it so. But even if we assume that the paper is valid, it is
important to understand just what it says, and not extrapolate too far.


This paper is actually a replication. It is notable for how comprehensive it is.


The paper makes various assumptions, takes statistical samples, and uses
models. (Which of course *any* such study must.) I'm not able to comment
on whether those models and assumptions are valid, but assuming that they
are, the conclusion of the paper is no stronger than the models and
assumptions. We should not really conclude that "CC has no more
predictive power than LOC". The right conclusion is that one specific
model of cyclic complexity, McCabe's CC, has no more predictive power
than LOC for projects written in C, C++ and Java.

How does that apply to Python code? Well, it's certainly suggestive, but
it isn't definitive.


More so than the evidence that CC is a worthwhile measure, for Python or any 
language.



It's also important to note that the authors point out that in their
samples of code, they found very high variance and large numbers of
outliers:

[quote]
Modules where LOC does not predict CC (or vice-versa) may indicate an
overly-complex module with a high density of decision points or an overly-
simple module that may need to be refactored.
[end quote]

So *even by the terms of this paper*, it isn't true that CC has no
predictive value over LOC -- if the CC is radically high or low for the
LOC, that is valuable to know.


Is it? What is the evidence that excess, unpredicted-by-LoC CC causes (or even 
correlates with) bugs? The paper points that out as a target for future research 
because no one has studied it yet. It may turn out to be a valid metric, but one 
that has a very specific utility: identifying a particular hotspot. Running CC 
over whole projects to compare their "quality", as the OP has done, is not a 
valid use of even that.



LoC is much simpler, easier to understand, and
easier to correct than CC.


Well, sure, but do you really think Perl one-liners are the paragon of
bug-free code we ought to be aiming for? *wink*


No, but introducing more statements and method calls to avoid if statements 
isn't either.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

Chris,

The focus of development team is controlled by setting a metric threshold or 
just excluding some. So you do not have an overhead for the development team 
from the point it set forward, assuming them team committed to adherence it.

Your strategy for perfection may vary. You can start with 8 for CC in new 
project, or with a higher level of 15 in an existing project. Where you end up 
/ the team agrees upon, depends on team commitment to the goal you set. There 
is no gold median, there is just recommendation, how you fluctuate from it and 
what reason you face with depends on team.

Thanks.

Andriy



> Date: Wed, 21 Nov 2012 22:21:23 +1100
> Subject: Re: Web Frameworks Excessive Complexity
> From: ros...@gmail.com
> To: python-list@python.org
>
> On Wed, Nov 21, 2012 at 10:09 PM, Andriy Kornatskyy
>  wrote:
> > We choose Python for its readability. This is essential principal of 
> > language and thousands around reading the open source code. Things like 
> > PEP8, CC, LoC are all to serve you one purpose: bring your attention, teach 
> > you make your code better.
>
> But too much focus on metrics results in those metrics improving
> without any material benefit to the code. If there's a number that you
> can watch going up or down, nobody's going to want to be the one that
> pushes that number the wrong direction. So what happens when the right
> thing to do happens to conflict with the given metric? And yes, it
> WILL happen, guaranteed. No metric is perfect.
>
> Counting lines of code teaches you to make dense code. That's not a
> good thing nor a bad thing; you'll end up with list comprehensions
> rather than short loops, regardless of which is easier to actually
> read.
>
> Counting complexity by giving a score to every statement encourages
> code like this:
>
> def bletch(x,y):
> return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
>
> instead of:
>
> def bletch(x,y):
> if mode=="foo": return x+y*2
> if mode=="bar": return x*4+y
> if mode=="quux": return x+math.sin(y)
> return x
>
> Okay, this is a stupid contrived example, but tell me which of those
> you'd rather work with, and then tell me a plausible metric that would
> agree with you.
>
> ChrisA
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Steven D'Aprano]

On Wed, 21 Nov 2012 22:21:23 +1100, Chris Angelico wrote:

> Counting complexity by giving a score to every statement encourages code
> like this:
> 
> def bletch(x,y):
>   return x + {"foo":y*2,"bar":x*3+y,"quux":math.sin(y)}.get(mode,0)
> 
> instead of:
> 
> def bletch(x,y):
>   if mode=="foo": return x+y*2
>   if mode=="bar": return x*4+y
>   if mode=="quux": return x+math.sin(y) return x
> 
> Okay, this is a stupid contrived example, but tell me which of those
> you'd rather work with


Am I being paid by the hour or the line?




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

We choose Python for its readability. This is essential principal of language 
and thousands around reading the open source code. Things like PEP8, CC, LoC 
are all to serve you one purpose: bring your attention, teach you make your 
code better.

Thanks.

Andriy



> From: ulrich.eckha...@dominolaser.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Wed, 21 Nov 2012 09:33:09 +0100
> To: python-list@python.org
>
> Am 21.11.2012 02:43, schrieb Steven D'Aprano:
> > On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote:
> >> The source of bugs is not excessive complexity in a method, just
> >> excessive lines of code.
> >
> > Taken literally, that cannot possibly the case.
> >
> > def method(self, a, b, c):
> > do_this(a)
> > do_that(b)
> > do_something_else(c)
> >
> >
> > def method(self, a, b, c):
> > do_this(a); do_that(b); do_something_else(c)
> >
> >
> > It *simply isn't credible* that version 1 is statistically likely to have
> > twice as many bugs as version 2. Over-reliance on LOC is easily gamed,
> > especially in semicolon languages.
>
> "Don't indent deeper than 4 levels!" "OK, not indenting at all, $LANG
> doesn't need it anyway." Sorry, but if code isn't even structured
> halfway reasonably it is unmaintainable, regardless of what CC or LOC say.
>
>
> > Besides, I think you have the cause and effect backwards. I would rather
> > say:
> >
> > The source of bugs is not lines of code in a method, but excessive
> > complexity. It merely happens that counting complexity is hard, counting
> > lines of code is easy, and the two are strongly correlated, so why count
> > complexity when you can just count lines of code?
>
> I agree here, and I'd go even further: Measuring complexity is not just
> hard, it requires a metric that you need to agree on first. With LOC you
> only need to agree on not semicolon-chaining lines and how to treat
> comments and empty lines. With CC, you effectively agree that an if
> statement has complexity of one (or 2?) while a switch statement has a
> complexity according to its number of cases, while it is way easier to
> read and comprehend than a similar number produced by if statement.
> Also, CC doesn't even consider new-fashioned stuff like exceptions that
> introduce yet another control flow path.
>
>
> >> LoC is much simpler, easier to understand, and
> >> easier to correct than CC.
> >
> > Well, sure, but do you really think Perl one-liners are the paragon of
> > bug-free code we ought to be aiming for? *wink*
>
> Hehehe... ;)
>
> Uli
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

Robert,

You would never get a better product by accident.

The meaning of better product might differ from team to team but you can not 
ignore excessive complexity. Earlier or later you get back to that code and 
refactor it, thus existence of such fact was driven by your intention to make 
it a bit better (easier to understand, to support, to cover with unit tests, 
etc), with a team of 20 heads you can get even further: the whole 
team adherence. So those drops make the overall picture better. This is what 
you, as a software developer, donate to what the final better product become.

Thanks.

Andriy



> To: python-list@python.org
> From: robert.k...@gmail.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Tue, 20 Nov 2012 20:33:46 +
>
> On 20/11/2012 20:22, Andriy Kornatskyy wrote:
> >
> > Robert,
> >
> > I respect your point of view and it definitely make sense to me. I 
> > personally do not have a problem to understand CC but agree, method LoC is 
> > easier to understand. Regardless the path your choose in your next 
> > refactoring (based on method CC, LoC) it gives your better product.
>
> No, refactoring based on CC does not give you a better product, except by 
> accident.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
> that is made terrible by our own mad attempt to interpret it as though it had
> an underlying truth."
> -- Umberto Eco
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Ulrich Eckhardt]

Am 21.11.2012 02:43, schrieb Steven D'Aprano:

On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote:

The source of bugs is not excessive complexity in a method, just
excessive lines of code.


Taken literally, that cannot possibly the case.

def method(self, a, b, c):
 do_this(a)
 do_that(b)
 do_something_else(c)


def method(self, a, b, c):
 do_this(a); do_that(b); do_something_else(c)


It *simply isn't credible* that version 1 is statistically likely to have
twice as many bugs as version 2. Over-reliance on LOC is easily gamed,
especially in semicolon languages.


"Don't indent deeper than 4 levels!" "OK, not indenting at all, $LANG 
doesn't need it anyway." Sorry, but if code isn't even structured 
halfway reasonably it is unmaintainable, regardless of what CC or LOC say.




Besides, I think you have the cause and effect backwards. I would rather
say:

The source of bugs is not lines of code in a method, but excessive
complexity. It merely happens that counting complexity is hard, counting
lines of code is easy, and the two are strongly correlated, so why count
complexity when you can just count lines of code?


I agree here, and I'd go even further: Measuring complexity is not just 
hard, it requires a metric that you need to agree on first. With LOC you 
only need to agree on not semicolon-chaining lines and how to treat 
comments and empty lines. With CC, you effectively agree that an if 
statement has complexity of one (or 2?) while a switch statement has a 
complexity according to its number of cases, while it is way easier to 
read and comprehend than a similar number produced by if statement. 
Also, CC doesn't even consider new-fashioned stuff like exceptions that 
introduce yet another control flow path.




LoC is much simpler, easier to understand, and
easier to correct than CC.


Well, sure, but do you really think Perl one-liners are the paragon of
bug-free code we ought to be aiming for? *wink*


Hehehe... ;)

Uli


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

Re: Web Frameworks Excessive Complexity

[Steven D'Aprano]

On Tue, 20 Nov 2012 20:07:54 +, Robert Kern wrote:

> The source of bugs is not excessive complexity in a method, just
> excessive lines of code.

Taken literally, that cannot possibly the case.

def method(self, a, b, c):
do_this(a)
do_that(b)
do_something_else(c)


def method(self, a, b, c):
do_this(a); do_that(b); do_something_else(c)


It *simply isn't credible* that version 1 is statistically likely to have 
twice as many bugs as version 2. Over-reliance on LOC is easily gamed, 
especially in semicolon languages.

Besides, I think you have the cause and effect backwards. I would rather 
say:

The source of bugs is not lines of code in a method, but excessive 
complexity. It merely happens that counting complexity is hard, counting 
lines of code is easy, and the two are strongly correlated, so why count 
complexity when you can just count lines of code?



Keep in mind that something like 70-80% of published scientific papers 
are never replicated, or cannot be replicated. Just because one paper 
concludes that LOC alone is a better metric than CC doesn't necessary 
make it so. But even if we assume that the paper is valid, it is 
important to understand just what it says, and not extrapolate too far.

The paper makes various assumptions, takes statistical samples, and uses 
models. (Which of course *any* such study must.) I'm not able to comment 
on whether those models and assumptions are valid, but assuming that they 
are, the conclusion of the paper is no stronger than the models and 
assumptions. We should not really conclude that "CC has no more 
predictive power than LOC". The right conclusion is that one specific 
model of cyclic complexity, McCabe's CC, has no more predictive power 
than LOC for projects written in C, C++ and Java.

How does that apply to Python code? Well, it's certainly suggestive, but 
it isn't definitive.

It's also important to note that the authors point out that in their 
samples of code, they found very high variance and large numbers of 
outliers:

[quote]
Modules where LOC does not predict CC (or vice-versa) may indicate an 
overly-complex module with a high density of decision points or an overly-
simple module that may need to be refactored.
[end quote]

So *even by the terms of this paper*, it isn't true that CC has no 
predictive value over LOC -- if the CC is radically high or low for the 
LOC, that is valuable to know.


> LoC is much simpler, easier to understand, and
> easier to correct than CC.

Well, sure, but do you really think Perl one-liners are the paragon of 
bug-free code we ought to be aiming for? *wink*



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Robert Kern]

On 20/11/2012 20:22, Andriy Kornatskyy wrote:


Robert,

I respect your point of view and it definitely make sense to me. I personally 
do not have a problem to understand CC but agree, method LoC is easier to 
understand. Regardless the path your choose in your next refactoring (based on 
method CC, LoC) it gives your better product.


No, refactoring based on CC does not give you a better product, except by 
accident.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

Robert,

I respect your point of view and it definitely make sense to me. I personally 
do not have a problem to understand CC but agree, method LoC is easier to 
understand. Regardless the path your choose in your next refactoring (based on 
method CC, LoC) it gives your better product.

Andriy


> To: python-list@python.org
> From: robert.k...@gmail.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Tue, 20 Nov 2012 20:07:54 +
>
> On 20/11/2012 19:46, Andriy Kornatskyy wrote:
> >
> > Robert,
> >
> > Thank you for the comment. I do not try relate CC with LOC. Instead 
> > pointing to excessive complexity, something that is beyond recommended 
> > threshold, a subject to refactoring in respective web frameworks. Those 
> > areas are likely to be potential source of bugs (e.g. due to low code 
> > coverage with unit tests) thus have certain degree of interest to both: end 
> > users and framework developers.
>
> Did you read the paper? I'm not suggesting that you compare CC with LoC; I'm
> suggesting that you don't use CC as a metric at all. The research is fairly
> conclusive that CC doesn't measure what you think it measures. The source of
> bugs is not excessive complexity in a method, just excessive lines of code. 
> LoC
> is much simpler, easier to understand, and easier to correct than CC.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
> that is made terrible by our own mad attempt to interpret it as though it had
> an underlying truth."
> -- Umberto Eco
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Robert Kern]

On 20/11/2012 19:46, Andriy Kornatskyy wrote:


Robert,

Thank you for the comment. I do not try relate CC with LOC. Instead pointing to 
excessive complexity, something that is beyond recommended threshold, a subject 
to refactoring in respective web frameworks. Those areas are likely to be 
potential source of bugs (e.g. due to low code coverage with unit tests) thus 
have certain degree of interest to both: end users and framework developers.


Did you read the paper? I'm not suggesting that you compare CC with LoC; I'm 
suggesting that you don't use CC as a metric at all. The research is fairly 
conclusive that CC doesn't measure what you think it measures. The source of 
bugs is not excessive complexity in a method, just excessive lines of code. LoC 
is much simpler, easier to understand, and easier to correct than CC.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

RE: Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

Robert,

Thank you for the comment. I do not try relate CC with LOC. Instead pointing to 
excessive complexity, something that is beyond recommended threshold, a subject 
to refactoring in respective web frameworks. Those areas are likely to be 
potential source of bugs (e.g. due to low code coverage with unit tests) thus 
have certain degree of interest to both: end users and framework developers.

Thanks.

Andriy Kornatskyy



> To: python-list@python.org
> From: robert.k...@gmail.com
> Subject: Re: Web Frameworks Excessive Complexity
> Date: Tue, 20 Nov 2012 19:32:31 +
>
> On 20/11/2012 17:41, Andriy Kornatskyy wrote:
> >
> > Cyclomatic (or conditional) complexity is a metric used to indicate the 
> > complexity of a source code. Excessive complexity is something that is 
> > beyond recommended
> > level of 10 (threshold that points to the fact the source code is too
> > complex and refactoring is suggested). Here is a list of web frameworks 
> > examined: bottle, cherrypy, circuits,
> > django, flask, pyramid, pysi, tornado, turbogears, web.py, web2py and
> > wheezy.web.
>
> Cyclomatic complexity tells you nothing that counting lines of code doesn't 
> already.
>
> http://www.scirp.org/Journal/PaperInformation.aspx?paperID=779
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
> that is made terrible by our own mad attempt to interpret it as though it had
> an underlying truth."
> -- Umberto Eco
>
> --
> http://mail.python.org/mailman/listinfo/python-list
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Web Frameworks Excessive Complexity

[Robert Kern]

On 20/11/2012 17:41, Andriy Kornatskyy wrote:


Cyclomatic (or conditional) complexity is a metric used to indicate the 
complexity of a source code. Excessive complexity is something that is beyond 
recommended
level of 10 (threshold that points to the fact the source code is too
complex and refactoring is suggested). Here is a list of web frameworks 
examined: bottle, cherrypy, circuits,
django, flask, pyramid, pysi, tornado, turbogears, web.py, web2py and
wheezy.web.


Cyclomatic complexity tells you nothing that counting lines of code doesn't 
already.

  http://www.scirp.org/Journal/PaperInformation.aspx?paperID=779

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

Web Frameworks Excessive Complexity

[Andriy Kornatskyy]

Cyclomatic (or conditional) complexity is a metric used to indicate the 
complexity of a source code. Excessive complexity is something that is beyond 
recommended 
level of 10 (threshold that points to the fact the source code is too 
complex and refactoring is suggested). Here is a list of web frameworks 
examined: bottle, cherrypy, circuits, 
django, flask, pyramid, pysi, tornado, turbogears, web.py, web2py and 
wheezy.web.

You can read more here:

http://mindref.blogspot.com/2012/11/python-web-excessive-complexity.html

Thanks.

Comments or suggestions are welcome.

Andriy Kornatskyy
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Python Web Frameworks PEP8 Consistency

[Andriy Kornatskyy]

The code is read much more often than it is written. The PEP8 guidelines are 
intended to improve the readability of code. We will take a look at web 
frameworks source code readability 
(bottle, cherrypy, circuits, django, flask, pyramid, tornado, web.py, web2py 
and wheezy.web):

http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html

The ratio between a web framework total python source lines to PEP8 errors 
found represents PEP8 error rate in respectful framework.

Readability counts, no doubt, but readability consistency is important, it is 
equally important to know when to be inconsistent. The report makes excuse for 
the following:

E501 line too long (> 79 characters)
E231 missing whitespace after ',:'
W291 trailing whitespace
W293 blank line contains whitespace

Comments or suggestions are welcome.

Thanks.

Andriy Kornatskyy
  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Your favorite test tool and automation frameworks

[Mark Lawrence]

On 27/08/2012 12:04, Alex Naumov wrote:

Hello everybody,

I would like to ask about your favorite python test frameworks. I never
used it before (beginner in testing) and would like to start to learn Unit-
and GUI-testing.

I look now at PyUnit/unittest and dogtail. Maybe someone
can recommend something better or just share experiences?


Thank you,
Alex





I never test my own code as it's always perfect first time :)  For those 
who lack my talents here's a good starting point 
http://wiki.python.org/moin/PythonTestingToolsTaxonomy


--
Cheers.

Mark Lawrence.

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

Your favorite test tool and automation frameworks

[Alex Naumov]

Hello everybody,

I would like to ask about your favorite python test frameworks. I never
used it before (beginner in testing) and would like to start to learn Unit-
and GUI-testing.

I look now at PyUnit/unittest and dogtail. Maybe someone
can recommend something better or just share experiences?


Thank you,
Alex
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Database access benchmarks for use in web-frameworks - How does Python compare?

[Stefan Behnel]

Alec Taylor, 03.11.2011 11:19:

I'm building a large e-commerce site, and it is very important that
what I write can:
- Handle larger server load
- Deliver pages quickly
- Make transactions quickly


Those are pretty broad requirements. If a framework can satisfy them or not 
depends more on how you set it up and deploy it (e.g. how many servers you 
run, what kind of load balancing you use, how you serve your static 
content, etc.) than the actual framework you choose, I'd say.




as well as have a small development time (i.e. pre-built modules for
e-commerce are available, and extendible).


"e-commerce" is also a very broad term. But I'd expect that any of the 
recent web frameworks (certainly including Django) will satisfy your needs 
in some way.




Are there recent accessible statistics available, comparing these
metrics across the most popular web-frameworks? (i.e. Symfony, DJango,
Rails, ASP.NET&etc)


Not that I know of.

Stefan

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

Re: Database access benchmarks for use in web-frameworks - How does Python compare?

[88888 Dihedral]

I suggest that the use of dynamical page forwarding to different severs which 
run the same software package. This can be done in python!   
-- 
http://mail.python.org/mailman/listinfo/python-list

Database access benchmarks for use in web-frameworks - How does Python compare?

[Alec Taylor]

Good afternoon,

I'm building a large e-commerce site, and it is very important that
what I write can:
- Handle larger server load
- Deliver pages quickly
- Make transactions quickly

as well as have a small development time (i.e. pre-built modules for
e-commerce are available, and extendible).

Are there recent accessible statistics available, comparing these
metrics across the most popular web-frameworks? (i.e. Symfony, DJango,
Rails, ASP.NET &etc)

Thanks for all suggestions,

Alec Taylor
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to select Python web frameworks and which one is the best framework ?

[Kushal Kumaran]

On Thu, May 19, 2011 at 9:23 AM, VGNU Linux  wrote:
>
>
> On Tue, May 17, 2011 at 1:20 PM, VGNU Linux  wrote:
>>
>> Hi all,
>> I am confused on which web framework to select for developing a small data
>> driven web application. Application will have features generally found in
>> now-a-days web application like security, database connectivity,
>> authentication etc. I found few web frameworks over the net like django,
>> zope 2/3, pylons, turbogears, web2py, grok etc. etc.
>> I just want to know that how developers/managers/organizations select a
>> framework which best suits their needs ? what are the parameters for
>> selection ?
>> also which is the best and widely used web framework for python ?
>> I apologize if this is a repeated question.
>
> Please guys help as I am novice to web development.

Search the list archives.  This topic has been discussed many many times.

-- 
regards,
kushal
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How to select Python web frameworks and which one is the best framework ?

[VGNU Linux]

On Tue, May 17, 2011 at 1:20 PM, VGNU Linux  wrote:

> Hi all,
>
> I am confused on which web framework to select for developing a small data
> driven web application. Application will have features generally found in
> now-a-days web application like security, database connectivity,
> authentication etc. I found few web frameworks over the net like django,
> zope 2/3, pylons, turbogears, web2py, grok etc. etc.
> I just want to know that how developers/managers/organizations select a
> framework which best suits their needs ? what are the parameters for
> selection ?
> also which is the best and widely used web framework for python ?
>
> I apologize if this is a repeated question.
>
> Regards,
> VGNU
>

Please guys help as I am novice to web development.

Regards,
VGNU
-- 
http://mail.python.org/mailman/listinfo/python-list

How to select Python web frameworks and which one is the best framework ?

[VGNU Linux]

Hi all,

I am confused on which web framework to select for developing a small data
driven web application. Application will have features generally found in
now-a-days web application like security, database connectivity,
authentication etc. I found few web frameworks over the net like django,
zope 2/3, pylons, turbogears, web2py, grok etc. etc.
I just want to know that how developers/managers/organizations select a
framework which best suits their needs ? what are the parameters for
selection ?
also which is the best and widely used web framework for python ?

I apologize if this is a repeated question.

Regards,
VGNU
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python test frameworks

[Kev Dwyer]

On Sun, 07 Nov 2010 09:01:42 -0800, rustom wrote:

> On Nov 7, 7:09 pm, Kev Dwyer  wrote:
>> On Sun, 07 Nov 2010 10:56:46 +0530, Rustom Mody wrote:
>> > There are a large number of test frameworks in/for python.  Apart
>> > from what comes builtin with python there seems to be nose, staf,
>> > qmtest etc etc.
>>
>> > Is there any central place where these are listed with short
>> > descriptions? 'Test framework' means widely different things in
>> > different contexts. Any explanations/tutorials around?
>>
>> > [Disclaimer: I was educated a couple of decades before the TDD rage]
>>
>> Hello,
>>
>> You could start
>> withhttp://pycheesecake.org/wiki/PythonTestingToolsTaxonomy
>>
>> Kev
> 
> Thanks -- that looks like a comprehensive resource.  But it does not
> have staf
> http://staf.sourceforge.net/current/STAFPython.htm. Is that merely an
> item missing or a category?

I'm afraid I couldn't say with any certainty - I'd throw that question 
at the python testing newsgroup, to whom I am cross-posting in the hope 
that they can help.

Kev

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

Re: python test frameworks

[rustom]

On Nov 7, 7:09 pm, Kev Dwyer  wrote:
> On Sun, 07 Nov 2010 10:56:46 +0530, Rustom Mody wrote:
> > There are a large number of test frameworks in/for python.  Apart from
> > what comes builtin with python there seems to be nose, staf, qmtest etc
> > etc.
>
> > Is there any central place where these are listed with short
> > descriptions? 'Test framework' means widely different things in
> > different contexts. Any explanations/tutorials around?
>
> > [Disclaimer: I was educated a couple of decades before the TDD rage]
>
> Hello,
>
> You could start withhttp://pycheesecake.org/wiki/PythonTestingToolsTaxonomy
>
> Kev

Thanks -- that looks like a comprehensive resource.  But it does not
have staf
http://staf.sourceforge.net/current/STAFPython.htm.
Is that merely an item missing or a category?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python test frameworks

[Kev Dwyer]

On Sun, 07 Nov 2010 10:56:46 +0530, Rustom Mody wrote:

> There are a large number of test frameworks in/for python.  Apart from
> what comes builtin with python there seems to be nose, staf, qmtest etc
> etc.
> 
> Is there any central place where these are listed with short
> descriptions? 'Test framework' means widely different things in
> different contexts. Any explanations/tutorials around?
> 
> [Disclaimer: I was educated a couple of decades before the TDD rage]

Hello,

You could start with http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy

Kev

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

python test frameworks

[Rustom Mody]

There are a large number of test frameworks in/for python.  Apart from
what comes builtin with python there seems to be nose, staf, qmtest
etc etc.

Is there any central place where these are listed with short descriptions?
'Test framework' means widely different things in different contexts.
Any explanations/tutorials around?

[Disclaimer: I was educated a couple of decades before the TDD rage]
-- 
http://mail.python.org/mailman/listinfo/python-list

High(er) level frameworks that wrap Tkinter/ttk?

[python]

Curious if there are any higher level frameworks that attempt to
wrap Tkinter? For example, wxPython is wrapped by the Dabo
framework (http://dabodev.com/) and PythonCard.

Motivation: We've recently moved to Python 2.7 (Windows) and are
very impressed with the new ttk (Tile) support which allows one
to build professional quality, platform native GUI's using the
built-in Tkinter framework. In the past we would have used
wxPython to create simple GUI interfaces for our command line
utilities, but we're re-thinking this strategy in favor of using
Tkinter/ttk for these use cases.

Thanks,
Malcolm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How decoupled are the Python frameworks?

[mdipierro]

Interesting post. I would like to make some comments about design
decisions that went into web2py:

- For each app Model/View/Controllers/Language Files/Static Files/
Modules/Cron Tasks are stored in separated folders
- You can code only the models (no controllers and no view) and you
get a fully functional admin interface
- You can develop only controllers (with or without models but no
views) and you get a fully working application with workflow
- There is a convention for dispatching. You can override it with
routes.
- There is no metadata in the framework. URLs are mapped into an app
(within the web2py instance), into a controller file, and into a
function (action) in that controller file.
- You can have multiple apps within a web2py instance (they can be
installed, uninstalled, packaged, compiled without restarting web2py)
- You can have multiple model files, multiple controllers and multiple
views. You can override the mapping between controllers and default
views.
- You can group files (models/controllers/views/static files)
functionally into plugins. Plugins can be packaged separately from the
app and applied to multiple apps.
- Plugins expose components (i.e. reusable objects that can be
embedded in a page and talk to their own controllers via ajax).
- Plugin components are coded as any other web2py models/controller/
view but the form submission is automatically trapped (transparently
to the user) and executed via ajax so that, if the component contains
a form only the component is reloaded upon submissions of the form.
- web2py supports FORM, SQLFORM, SQLFORM.factory and CRUD for
automtical generation of forms (from a model or other structure). All
web2py forms execute postbacks and modify themselves to report error
messages. A form is comprised of widgets that contain validators.
There is a default layout but it can be customized in the view by
allocating widgets or individual html tags.
- You can put doctests in actions and we provide a web interface for
testing the app online.
- It completely abstracts the database backend (we support 10
different database backends including Google App Engine) thus make the
code very portable.
- It authomatically writes sql for queries, for create table and alter
table.
-Web2py provides a Role Based Access Control mechanism with plugguble
login components so that you can authenticate using multiple mechanism
including Gmail and Twitter for example.

Specifically about you concerns:- better scalability
- easy to test => web2py is very easy to test because of the web based
interface to doctests
- easy to maintain => In web2py "Do not repeat yourself" trumps
"explicit if better than implicit". This means code is very compact.
- easy to re-use code for different applications => using plugins
- easy to migrate/port => because of DAL

Massimo

On Dec 7, 4:38 pm, shocks  wrote:
> Hi
>
> I'm getting back into Python after a long break.  I've been developing
> large enterprise apps solely with Adobe Flex (ActionScript) for the
> past couple years.  During that time I've used a number of 'MVC'
> frameworks to glue the bits together - among them Cairngorm, a
> modified implementation of Cairngorm using the Presentation Model
> pattern, PureMVC, Mate (an IOC container but with an MVC
> implementation) and Parsley (IOC but you have to roll-you-own MVC).
> During that time I've been in large teams (30 Flex + 30 Java) to small
> teams (2 Flex + 1 Java).  The motivation of these frameworks is the
> decouple your concerns, allowing your apps to be more scalable, easier
> to test, and  supposedly easier to maintain.  Some do the decoupling
> better job than others, but there is also the question of "how
> decoupled is your code from the framework"?  It's all well and good
> having something clever working behind the scenes wiring and routing
> everything together, but I wonder where this leaves the code base if
> the framework, which was selected at the beginning of the project, is
> replaced with something else months or years later (i.e. the framework
> just doesn't scale as expected, the community involvement dies and
> it's no longer maintained properly, etc).  I've seen it happen and
> I've been experienced the pain of detangling massive amounts of code
> which is full of framework specific imports, methods and boilerplate
> code.  And then there's updating the unit tests!
>
> My question is how good are the current crop of Python frameworks?
> I've used Django twice in production and didn't like that much.  The
> implementation is Django specific for starters.  I've picked up Pylons
> and I'm trying that out.  I'm not sure how well it fares?  I do feel a
> bit uneasy about the code generation that some of the Python
> frameworks do.  Pylons creat

Re: How decoupled are the Python frameworks?

[Martin Sand Christensen]

Lie Ryan  writes:

> In the end, it is the developer's responsibility not to write
> something too tightly coupled with their framework, isn't it? (or at
> least to minimize the framework-specific code to a certain area)

That's a good summary of my point. However, I have very little
experience with other frameworks than CherryPy, so I do not want to draw
any general conclusions. My programmer's instincts say that it's true,
though.

-- 
Martin Sand Christensen
IT Services, Dept. of Electronic Systems
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How decoupled are the Python frameworks?

[Diez B. Roggisch]

shocks wrote:

> Hi
> 
> I'm getting back into Python after a long break.  I've been developing
> large enterprise apps solely with Adobe Flex (ActionScript) for the
> past couple years.  During that time I've used a number of 'MVC'
> frameworks to glue the bits together - among them Cairngorm, a
> modified implementation of Cairngorm using the Presentation Model
> pattern, PureMVC, Mate (an IOC container but with an MVC
> implementation) and Parsley (IOC but you have to roll-you-own MVC).
> During that time I've been in large teams (30 Flex + 30 Java) to small
> teams (2 Flex + 1 Java).  The motivation of these frameworks is the
> decouple your concerns, allowing your apps to be more scalable, easier
> to test, and  supposedly easier to maintain.  Some do the decoupling
> better job than others, but there is also the question of "how
> decoupled is your code from the framework"?  It's all well and good
> having something clever working behind the scenes wiring and routing
> everything together, but I wonder where this leaves the code base if
> the framework, which was selected at the beginning of the project, is
> replaced with something else months or years later (i.e. the framework
> just doesn't scale as expected, the community involvement dies and
> it's no longer maintained properly, etc).  I've seen it happen and
> I've been experienced the pain of detangling massive amounts of code
> which is full of framework specific imports, methods and boilerplate
> code.  And then there's updating the unit tests!
> 
> My question is how good are the current crop of Python frameworks?
> I've used Django twice in production and didn't like that much.  The
> implementation is Django specific for starters.  I've picked up Pylons
> and I'm trying that out.  I'm not sure how well it fares?  I do feel a
> bit uneasy about the code generation that some of the Python
> frameworks do.  Pylons creates something like 20 files for a
> 'helloworld'.  It does do some great things out of the box, but I
> wonder where that leaves your own code.  After spending 3-6 months on
> your Pylons webapp, how easy is it to move to something else?  Maybe
> one of the Python IOC once they mature.  What are some good techniques
> people are using to future (framework) proof their apps?
> 
> I'm interested to hear people experiences with the various frameworks
> and how decoupled their code is from them.  The best of the current
> Flex frameworks for me is Parsley.  The only noticeable Parlsey code
> is an '[Inject]' meta tag here and there and a couple import
> statements.  All the complicated object creation and messaging is done
> higher up the chain.

I think the Pylons and maybe even TurboGears2 stack are pretty good
regarding decoupling. This stems from them bundling "best-of-breed"
solutions for e.g. ORM (SQLAlchemy), session-handling, HTML-widgets,
templating and so forth together. So in theory, and to a large extend in
practice, you can rip out individual components and replace them with ones
you prefer, and of course this overall design makes things more decoupled.

*However* there is only so much a framework can and does do when it's
supposed to stay out of your way. I for one think that e.g. the
repoze.who/what stack is an example of an over-generalization that leads to
much more hassle than it's worth it, all for the alledged advantages of
total decoupling and pluggability.

Mark Christensen wrote a blog-post about the whole coupling/de-coupling
issue:

http://compoundthinking.com/blog/index.php/2009/11/28/coupling-django-style/

Essentially, getting things *done* now is very important, and making
developers permanently jump through hoops just so they avoid coupling leads
eventually to something that is your own webframework - without the benefit
of participating on evolution of a common one that occasionally forces you
to adapt.

Diez


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

Re: How decoupled are the Python frameworks?

[Lie Ryan]

On 12/8/2009 9:11 PM, Martin Sand Christensen wrote:

If the user isn't currently signed in to our CAS, he'll be redirected to
the sign-in page and, after signing in, is returned to the page he
originally requested. The role decorator checks his privileges (based on
his CAS credentials) and either allows or denies him access. This adds
up to a LOT of framework-specific code that's been very easily factored
out. The CAS and role modules behind the decorators are, in turn,
generic frameworks that we've merely specialised for CherryPy. At some
point we'll get around to releasing some code. :-)


In the end, it is the developer's responsibility not to write something 
too tightly coupled with their framework, isn't it?

(or at least to minimize the framework-specific code to a certain area)
--
http://mail.python.org/mailman/listinfo/python-list

Re: How decoupled are the Python frameworks?

[Martin Sand Christensen]

J Kenneth King  writes:
> [...] (though it sounds like cherrypy would be very good at separating
> dispatching from application code).

True. In CherryPy, each page is represented by one method (the 'default'
method is an exception, but that's not for this discussion). This method
is expected to return a string representing the page/resource that the
user requested. At this simple level, CherryPy can be considered more or
less just a HTTP server and dispatcher.

However, we all know that this isn't where it ends. When we want to
handle cookies, we need framework-specific code. When we want to return
something other than HTML, we need framework-specific code. The list
goes on.

However, with a reasonable coding style, it can be quite practical to
separate strict application code from the framework-specific code. Here
the one-method,-one-page principle is a great help. For instance, we
quite often use decorators for such things as authentication and role
checking, which is both very practical and technically elegant. For
instance, if a user must have a CAS single sign-on identity AND, say,
the administrator role, we'd do as follows:

@cas
@role('administrator')
def protectedpage(self, ...):
# stuff

If the user isn't currently signed in to our CAS, he'll be redirected to
the sign-in page and, after signing in, is returned to the page he
originally requested. The role decorator checks his privileges (based on
his CAS credentials) and either allows or denies him access. This adds
up to a LOT of framework-specific code that's been very easily factored
out. The CAS and role modules behind the decorators are, in turn,
generic frameworks that we've merely specialised for CherryPy. At some
point we'll get around to releasing some code. :-)

As a slight aside, allow me to recommend Meld3 as a good templating
library. It's basically ElementTree with a lot of practical templating
stuff on top, so it's not a mini-language unto itself, and you don't
embed your code in the page.

-- 
Martin Sand Christensen
IT Services, Dept. of Electronic Systems
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: How decoupled are the Python frameworks?

[J Kenneth King]

shocks  writes:

> Hi
>
> I'm getting back into Python after a long break.  I've been developing
> large enterprise apps solely with Adobe Flex (ActionScript) for the
> past couple years.  During that time I've used a number of 'MVC'
> frameworks to glue the bits together - among them Cairngorm, a
> modified implementation of Cairngorm using the Presentation Model
> pattern, PureMVC, Mate (an IOC container but with an MVC
> implementation) and Parsley (IOC but you have to roll-you-own MVC).
> During that time I've been in large teams (30 Flex + 30 Java) to small
> teams (2 Flex + 1 Java).  The motivation of these frameworks is the
> decouple your concerns, allowing your apps to be more scalable, easier
> to test, and  supposedly easier to maintain.  Some do the decoupling
> better job than others, but there is also the question of "how
> decoupled is your code from the framework"?  It's all well and good
> having something clever working behind the scenes wiring and routing
> everything together, but I wonder where this leaves the code base if
> the framework, which was selected at the beginning of the project, is
> replaced with something else months or years later (i.e. the framework
> just doesn't scale as expected, the community involvement dies and
> it's no longer maintained properly, etc).  I've seen it happen and
> I've been experienced the pain of detangling massive amounts of code
> which is full of framework specific imports, methods and boilerplate
> code.  And then there's updating the unit tests!
>
> My question is how good are the current crop of Python frameworks?
> I've used Django twice in production and didn't like that much.  The
> implementation is Django specific for starters.  I've picked up Pylons
> and I'm trying that out.  I'm not sure how well it fares?  I do feel a
> bit uneasy about the code generation that some of the Python
> frameworks do.  Pylons creates something like 20 files for a
> 'helloworld'.  It does do some great things out of the box, but I
> wonder where that leaves your own code.  After spending 3-6 months on
> your Pylons webapp, how easy is it to move to something else?  Maybe
> one of the Python IOC once they mature.  What are some good techniques
> people are using to future (framework) proof their apps?
>
> I'm interested to hear people experiences with the various frameworks
> and how decoupled their code is from them.  The best of the current
> Flex frameworks for me is Parsley.  The only noticeable Parlsey code
> is an '[Inject]' meta tag here and there and a couple import
> statements.  All the complicated object creation and messaging is done
> higher up the chain.
>
> Cheers,
> Ben

I've stayed away from the Java world at least professionally... but I
think I understand where you're getting.

I'm not a huge fan of web development.  Which is rather
counter-intuitive for me to say since it's been the bulk of my work
for the past four years.  It's because there's no easy way to get
around the warts.  Websites are one thing but to try and think of
these things as "applications" becomes an expensive illusion to
maintain.

The problem with thinking about these things as applications with an
interface, a controller, and a model is: statelessness!  Oh also
serialization.  Getting around these issues are pretty much the raison
d'etre for web frameworks.  Without them we end up with PHP.

As far as swappable Python web frameworks... NONE. AFAIK, they all
require some commitment to tying your application to them.  However,
there are a crop of frameworks that do minimize the pain of such a
decision: web.py and bobo are two that I've been working with (though
it sounds like cherrypy would be very good at separating dispatching
from application code).  You could of course write your stuff closer
to the "metal" so to speak... WSGI would be about as low as I go.
-- 
http://mail.python.org/mailman/listinfo/python-list

How decoupled are the Python frameworks?

[shocks]

Hi

I'm getting back into Python after a long break.  I've been developing
large enterprise apps solely with Adobe Flex (ActionScript) for the
past couple years.  During that time I've used a number of 'MVC'
frameworks to glue the bits together - among them Cairngorm, a
modified implementation of Cairngorm using the Presentation Model
pattern, PureMVC, Mate (an IOC container but with an MVC
implementation) and Parsley (IOC but you have to roll-you-own MVC).
During that time I've been in large teams (30 Flex + 30 Java) to small
teams (2 Flex + 1 Java).  The motivation of these frameworks is the
decouple your concerns, allowing your apps to be more scalable, easier
to test, and  supposedly easier to maintain.  Some do the decoupling
better job than others, but there is also the question of "how
decoupled is your code from the framework"?  It's all well and good
having something clever working behind the scenes wiring and routing
everything together, but I wonder where this leaves the code base if
the framework, which was selected at the beginning of the project, is
replaced with something else months or years later (i.e. the framework
just doesn't scale as expected, the community involvement dies and
it's no longer maintained properly, etc).  I've seen it happen and
I've been experienced the pain of detangling massive amounts of code
which is full of framework specific imports, methods and boilerplate
code.  And then there's updating the unit tests!

My question is how good are the current crop of Python frameworks?
I've used Django twice in production and didn't like that much.  The
implementation is Django specific for starters.  I've picked up Pylons
and I'm trying that out.  I'm not sure how well it fares?  I do feel a
bit uneasy about the code generation that some of the Python
frameworks do.  Pylons creates something like 20 files for a
'helloworld'.  It does do some great things out of the box, but I
wonder where that leaves your own code.  After spending 3-6 months on
your Pylons webapp, how easy is it to move to something else?  Maybe
one of the Python IOC once they mature.  What are some good techniques
people are using to future (framework) proof their apps?

I'm interested to hear people experiences with the various frameworks
and how decoupled their code is from them.  The best of the current
Flex frameworks for me is Parsley.  The only noticeable Parlsey code
is an '[Inject]' meta tag here and there and a couple import
statements.  All the complicated object creation and messaging is done
higher up the chain.

Cheers,
Ben
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Emmanuel Surleau]

> Emmanuel Surleau a écrit :
> >>>>> It still manages to retain flexibility, but you're basically stuck
> >>>>> with Django's ORM
> >>>>
> >>>> You're by no way "stuck" with Django's ORM - you are perfectly free
> >>>> not to use it. But then you'll obviously loose quite a lot of useful
> >>>> features and 3rd part apps...
> >>>
> >>> You lose most of what makes it worth using Django,
> >>
> >> Mmmm... I beg to disagree. You still have the core framework (request /
> >> response handling, sessions etc), the templating system, the form API
> >> etc. As far as I'm concerned, it's quite enough to "make it worth".
> >
> > The form API is pretty good, but I don't think the rest makes it stand
> > out that much, compared to other frameworks.
> 
> I don't care if it "stand out that much" - it works fine and is well
> documented. Given that for most web apps, Django's ORM is a good enough
> tool, I don't see the point in using 3 or more "different" frameworks
> that basically do the same things in slightly different ways, each with
> it's own strong and weak points.

I think we'd be lucky to have just 3 :) But there are obviously advantages to 
something more modular like Pylons, and Tornado looks interesting as well 
(haven't used it yet, though). That's open-source for you.

> > To me, the notion of reusable apps
> > and the application ecosystem it allows is Django's most compelling
> > feature.
> 
> +1.

Thinking about it, that's where modularity can hurt, eg, Pylons. Developing a 
"reusable app" like Django's is more difficult if you don't know what ORM or 
templating system is being used. Unless you stick to the most popular choices, 
but this removes, in practice, flexibility for developers who need such apps.

> > You are, of course, welcome to disagree.
> 
> I'm not saying that Django is "better" than Pylons or web.py or (insert
> yur favorite framework here) - and to be true, I think Pylons is
> globally smarter than Django -, I'm saying that it do the job, and do it
> well enough to be worth using. Sorry for being so pragmatic.
> 
> >>> Having to implement a mini-parser for
> >>> each single tag
> >>
> >> Most of the "mini-parser" stuff is so very easily factored out I'm
> >> afraid I won't buy your argument.
> >
> > You'll at least agree that in terms of line of codes necessary to
> > implement a custom tag, it's very far from optimal, I hope?
> 
> I also agree that in terms of LOCs necessary to implement a log file
> parser, Python is also very far from optimal, at least compared to Perl !-)

I think that depends on how many regular expressions you use in your code. 
Think about all these lines with } you don't need any more. As far as 
languages go, Python strikes a good balance between readability and concision, 
really.

> How many Django custom tags did you write, exactly ? And of which level
> of complexity ? Once again, I'm not pretending Django is the best thing
> ever, but most of your remarks remind me of what I once could have say -
> that is, before having enough experience writing and maintaining Django
> apps. One of the greatest features of Django - and possibly what finally
> makes it so pythonic - is that it doesn't try to be *too* smart - just
> smart enough.

I'll grant you I don't have a huge experience with Django custom tags (or 
Django in general). Should I do more Django in the future, custom tags would 
irk me less (after all, I even got used to ASP, so...). This still does not 
make them particularly practical, though I agree that they are not a huge 
inconvenience.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Bruno Desthuilliers]

Emmanuel Surleau a écrit :

It still manages to retain flexibility, but you're basically stuck with
Django's ORM

You're by no way "stuck" with Django's ORM - you are perfectly free not
to use it. But then you'll obviously loose quite a lot of useful
features and 3rd part apps...

You lose most of what makes it worth using Django,

Mmmm... I beg to disagree. You still have the core framework (request /
response handling, sessions etc), the templating system, the form API
etc. As far as I'm concerned, it's quite enough to "make it worth".


The form API is pretty good, but I don't think the rest makes it stand out 
that much, compared to other frameworks.


I don't care if it "stand out that much" - it works fine and is well 
documented. Given that for most web apps, Django's ORM is a good enough 
tool, I don't see the point in using 3 or more "different" frameworks 
that basically do the same things in slightly different ways, each with 
it's own strong and weak points.


To me, the notion of reusable apps 
and the application ecosystem it allows is Django's most compelling feature.


+1.


You are, of course, welcome to disagree.


I'm not saying that Django is "better" than Pylons or web.py or (insert 
yur favorite framework here) - and to be true, I think Pylons is 
globally smarter than Django -, I'm saying that it do the job, and do it 
well enough to be worth using. Sorry for being so pragmatic.



Having to implement a mini-parser for
each single tag

Most of the "mini-parser" stuff is so very easily factored out I'm
afraid I won't buy your argument.


You'll at least agree that in terms of line of codes necessary to implement a 
custom tag, it's very far from optimal, I hope?


I also agree that in terms of LOCs necessary to implement a log file 
parser, Python is also very far from optimal, at least compared to Perl !-)


How many Django custom tags did you write, exactly ? And of which level 
of complexity ? Once again, I'm not pretending Django is the best thing 
ever, but most of your remarks remind me of what I once could have say - 
that is, before having enough experience writing and maintaining Django 
apps. One of the greatest features of Django - and possibly what finally 
makes it so pythonic - is that it doesn't try to be *too* smart - just 
smart enough.


My 2 cents.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Emmanuel Surleau]

> Emmanuel Surleau a écrit :
> >> Emmanuel Surleau a écrit :
> >>>> Django : very strong integration, excellent documentation and support,
> >>>> huge community, really easy to get started with. And possibly a bit
> >>>> more mature and stable...
> >>>
> >>> One strong point in favour of Django: it follows Python's philosophy of
> >>> "batteries included", and features a large array of plugins. There are
> >>> also numerous other add-ons created by the community.
> >>>
> >>> Also, it has a pretty great administration interface.
> >>>
> >>> It still manages to retain flexibility, but you're basically stuck with
> >>> Django's ORM
> >>
> >> You're by no way "stuck" with Django's ORM - you are perfectly free not
> >> to use it. But then you'll obviously loose quite a lot of useful
> >> features and 3rd part apps...
> >
> > You lose most of what makes it worth using Django,
> 
> Mmmm... I beg to disagree. You still have the core framework (request /
> response handling, sessions etc), the templating system, the form API
> etc. As far as I'm concerned, it's quite enough to "make it worth".

The form API is pretty good, but I don't think the rest makes it stand out 
that much, compared to other frameworks. To me, the notion of reusable apps 
and the application ecosystem it allows is Django's most compelling feature. 
You are, of course, welcome to disagree.

> > Having to implement a mini-parser for
> > each single tag
> 
> Most of the "mini-parser" stuff is so very easily factored out I'm
> afraid I won't buy your argument.

You'll at least agree that in terms of line of codes necessary to implement a 
custom tag, it's very far from optimal, I hope?

Cheers,

Emm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Bruno Desthuilliers]

Emmanuel Surleau a écrit :

Emmanuel Surleau a écrit :

Django : very strong integration, excellent documentation and support,
huge community, really easy to get started with. And possibly a bit more
mature and stable...

One strong point in favour of Django: it follows Python's philosophy of
"batteries included", and features a large array of plugins. There are
also numerous other add-ons created by the community.

Also, it has a pretty great administration interface.

It still manages to retain flexibility, but you're basically stuck with
Django's ORM

You're by no way "stuck" with Django's ORM - you are perfectly free not
to use it. But then you'll obviously loose quite a lot of useful
features and 3rd part apps...


You lose most of what makes it worth using Django,


Mmmm... I beg to disagree. You still have the core framework (request / 
response handling, sessions etc), the templating system, the form API 
etc. As far as I'm concerned, it's quite enough to "make it worth".



(which is OK for simple things) and templating language (which is
OK as long as you don't need custom tags).

Custom tags are nothing complicated.


Compared to custom tags in, say, Mako?


I lack _working_ experience with Mako (only played with it), but I found 
it to sometimes have a "bend backbward" feel. One nice thing with 
Django's templates is the very straightforward approach. Might not be as 
smart and elegant - and certainly not as powerful, I won't even discuss 
this point -, but hey, it JustWork(tm), and my fellow html coders can 
use it without difficulty.


Don't misunderstand me - as a computer programmer, I of course find Mako 
to be way above Django's template. But this doesn't make the latter bad, 
and from the average html coder POV Django is easier to grasp. But well, 
this has been debatted to hell and back, so let's not waste time with this.


Having to implement a mini-parser for 
each single tag


Most of the "mini-parser" stuff is so very easily factored out I'm 
afraid I won't buy your argument.

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

Re: Frameworks

[Emmanuel Surleau]

> On Oct 20, 2009, at 4:59 PM, Emmanuel Surleau wrote:
> > Compared to custom tags in, say, Mako? Having to implement a mini-
> > parser for
> > each single tag when you can write a stupid Python function is
> > needless
> > complication.
> 
> I like Mako a lot and in fact web2py template took some inspiration
> from it. Here is a mako example:
> 
> % for a in ['one', 'two', 'three', 'four', 'five']:
>  % if a[0] == 't':
>   its two or three
>  % elif a[0] == 'f':
>  four/five
>  % else:
>  ${a}
>  %endif
> % endfor
> 
> 
> Here is the same in web2py-ese, translated line by line
> 
>   {{for a in ['one', 'two', 'three', 'four', 'five']:}}
>  {{if a[0] == 't':}}
>   its two or three
>  {{elif a[0] == 'f':}}
>  four/five
>  {{else:}}
>  {{=a}}
>  {{pass}}
> {{pass}}
> 
> Legend Mako -> web2py
> % -> {{  }}
> endif -> pass
> endfor -> pass
> ${...} -> {{=...}}
> 
> Mako introduces terms like "endif", "endfor" which are not Python
> keywords. Web2py only uses valid python keywords.

Ingenious. Web2py looks more consistent (everything relies on {{ }} while Mako 
uses %, $ and <% >). On the other hand, the Mako syntax is a bit lighter to my 
eyes. Tradeoffs, tradeoffs...
 
> Here is another example, in Mako:
> 
> <%def name="myfunc(x)">
>  this is myfunc, x is ${x}
> 
> ${myfunc(7)}
> 
> and the same in web2py
> 
> {{def myfunc(x):}}
> this is myfunc, x is {{=x}}
> {{return}}
> {{myfunc(7)}}
> 
> Again web2py does not introduce any new syntax. only valid Python in
> {{...}} tags.
> (Notice {{myfunc(7)}} not {{=myfunc(7)}} becase the function is
> printing, we are not printing the return value of the function).
> 
> Mako needs to parse % ..., <%>..., ... and ${...}. web2py needs to
> parse only {{...}}.
> 
> The use of {{...}} in web2py is inspired by Django. This has a big
> advantage over <%...%>, it is transparent to html editors and so you
> use any html editor with the templates.

Bah, as if anyone needed anything else than vim :) Just joking, I see the 
advantage if you are working with external designers.

Cheers,

Emm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Massimo Di Pierro]

On Oct 20, 2009, at 4:59 PM, Emmanuel Surleau wrote:

Compared to custom tags in, say, Mako? Having to implement a mini- 
parser for
each single tag when you can write a stupid Python function is  
needless

complication.


I like Mako a lot and in fact web2py template took some inspiration  
from it. Here is a mako example:


% for a in ['one', 'two', 'three', 'four', 'five']:
% if a[0] == 't':
 its two or three
% elif a[0] == 'f':
four/five
% else:
${a}
%endif
% endfor


Here is the same in web2py-ese, translated line by line

 {{for a in ['one', 'two', 'three', 'four', 'five']:}}
{{if a[0] == 't':}}
 its two or three
{{elif a[0] == 'f':}}
four/five
{{else:}}
{{=a}}
{{pass}}
{{pass}}

Legend Mako -> web2py
% -> {{  }}
endif -> pass
endfor -> pass
${...} -> {{=...}}

Mako introduces terms like "endif", "endfor" which are not Python  
keywords. Web2py only uses valid python keywords.


Here is another example, in Mako:

<%def name="myfunc(x)">
this is myfunc, x is ${x}

${myfunc(7)}

and the same in web2py

{{def myfunc(x):}}
   this is myfunc, x is {{=x}}
{{return}}
{{myfunc(7)}}

Again web2py does not introduce any new syntax. only valid Python in  
{{...}} tags.
(Notice {{myfunc(7)}} not {{=myfunc(7)}} becase the function is  
printing, we are not printing the return value of the function).


Mako needs to parse % ..., <%>..., ... and ${...}. web2py needs to  
parse only {{...}}.


The use of {{...}} in web2py is inspired by Django. This has a big  
advantage over <%...%>, it is transparent to html editors and so you  
use any html editor with the templates.


Massimo




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

Re: Frameworks

[Emmanuel Surleau]

> Emmanuel Surleau a écrit :
> >> Django : very strong integration, excellent documentation and support,
> >> huge community, really easy to get started with. And possibly a bit more
> >> mature and stable...
> >
> > One strong point in favour of Django: it follows Python's philosophy of
> > "batteries included", and features a large array of plugins. There are
> > also numerous other add-ons created by the community.
> >
> > Also, it has a pretty great administration interface.
> >
> > It still manages to retain flexibility, but you're basically stuck with
> > Django's ORM
> 
> You're by no way "stuck" with Django's ORM - you are perfectly free not
> to use it. But then you'll obviously loose quite a lot of useful
> features and 3rd part apps...

You lose most of what makes it worth using Django, so you're in effect kind of 
stuck with it. If you don't need/want the ORM, you might as well use something 
else.

> > (which is OK for simple things) and templating language (which is
> > OK as long as you don't need custom tags).
> 
> Custom tags are nothing complicated.

Compared to custom tags in, say, Mako? Having to implement a mini-parser for 
each single tag when you can write a stupid Python function is needless 
complication.

Cheers,

Emm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[mdipierro]

One more clarification to avoid confusion. Django has "admin" and it
is great. Web2py also has something called "admin" but that is not
apples to apples.

The closest thing to Django "admin" in web2py is called "appadmin" (it
comes with it).

For example consider the following complete program:

db=DAL('sqlite://test.sqlite)
db.define_table('person',Field('name'))

appadmin is a controller that comes with each web2py app and provides
a web based interface to the database, that can be customized at the
app level, and that inherits the layout of the app.

The Django "admin" can be customized more and it is designed for
users. It is very sleek. The web2py "appadmin" is designed for the
administrator not users, and allows you to insert DAL queries
directly.

web2py also has something called "admin" which has nothing to do with
Django "admin". It is instead a web based IDE including web based
tools for installing apps remotely, packaging apps, editing apps,
debugging, running doctests, etc. via the web interface.

Massimo

On Oct 19, 4:54 pm, Emmanuel Surleau 
wrote:
> > Django : very strong integration, excellent documentation and support,
> > huge community, really easy to get started with. And possibly a bit more
> > mature and stable...
>
> One strong point in favour of Django: it follows Python's philosophy of
> "batteries included", and features a large array of plugins. There are also
> numerous other add-ons created by the community.
>
> Also, it has a pretty great administration interface.
>
> It still manages to retain flexibility, but you're basically stuck with
> Django's ORM (which is OK for simple things) and templating language (which is
> OK as long as you don't need custom tags).
>
> > Pylons : more loosely coupled (imply: less integration), based on
> > "standard" components - which is both a blessing and a curse, specially
> > wrt/ documentation -, requires a good knowledge of Python and the HTTP
> > protocol to get started with. Very powerful and flexible but this comes
> > with a price...
>
> Haven't used Pylons, but the documentation has improved the last few years
> with the Pylons book (http://pylonsbook.com/en/1.0/), while still not being up
> to par with Django's. It has also a methodology for deployment, which Django
> decidedly lacks.
>
> Cheers,
>
> Emm

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

Re: Frameworks

[mdipierro]

On Oct 19, 9:01 am, flebber  wrote:
> In short it seems to me that Django and Web2py include more "magic" in
> assisting oneself to create you web/application, whilst Pylons and
> Werkzueg leave more control in the users hands hopefully leading to
> greater expression and power.

it depends on how one defines "magic". web2py provides a DAL, not an
ORM. DAL expressions translate one-to-one into SQL statements in the
appropriate dialect (or GQL on GAE), no more, without additional
superstructure. The basic API are

   db.tablename.insert(filename=value)
   db(query).select(...)
   db(query).update(...)
   db(query).delete()
   db(query).count()

an example of query is

   query=(db.tablename.fieldname=='value')|(db.tablename.fieldname.like
('A%'))

which translates into

   WEHERE tablename.fieldname = 'value' OR tablename.fieldname LIKE 'A
%'

with the appropriate escaping for security or course.


Of course you can more complex expressions for nested selects, joins,
left joins, aggregates, etc. but the general principle stands. Here is
an example:


   db().select(db.table1.field1,db.table1.field2.sum
(),groupby=db.table1.field1)

and another (which does a nested select, a join and a left join):

   db((db.table1.field1.belongs(db(db.table2.field2.id>0)._select
(db.table2.field3)))&
  (db.table1.field4==db.table3.field5)).select
(
  db.table1.ALL,db.table2.field6,
  left=db.table4.on
(db.table4.field6==db.table1.field7),
  orderby=db.table1.field8)



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

Re: Frameworks

[Massimo Di Pierro]

> So does web2py allow for raw sql if there is an advanced procedure  
or query that needs to be performed that is outside the scope of the  
web2pr orm


Yes

db.executesql("whatever you want")

http://www.web2py.com/examples/static/epydoc/web2py.gluon.sql.SQLDB-class.html

Massimo
--
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Bruno Desthuilliers]

flebber a écrit :
(snip)

In short it seems to me that Django and Web2py include more "magic" in
assisting oneself to create you web/application, whilst Pylons and
Werkzueg leave more control in the users hands hopefully leading to
greater expression and power.


I can't tell much about web2py - never used it. wrt/ Django, there's not 
that much "magic" involved - Django's ORM is not "more magic" than 
SQLAlchemy, Django templates are by no mean "more magic" than Mako or 
Genshi (and probably way simpler to understand than Mako). And FWIW, 
Jinja started as a standalone rewrite of Django templates.


The main difference between Django and Pylons is that Django is highly 
'integrated' - all parts were designed by the same team, and were 
designed to work together - while Pylons is very loose - it's mainly an 
"assembly" of 3rd part components, most of them swappable, with some 
glue code to make the whole thing work. Very different philosophies.


Having serious working knowledge of Django, I don't buy the "Pylons 
gives you more control" stuff - you have as much "control" with Django, 
the only point is that you'll obviously loose some  hi-level features 
when using "non-standard" components. Pylons just don't have these 
features OOTB.



Pylons recommends SQLALchemy and Mako (offers Genshi and Jinja2) and
Werkzueg SQLAlchemy and Jinja2. As I don't have the experience to tell
the pro's cons of these two apart, would choosing Pylons based on
Documentation be a fair call?


If you know right from the start you won't need Django's hi-level 
features, and/or that the level of integration it offers will be more of 
a nuisance than help for your project, then go for 
Pylons/SQLAlchemy/Mako. It's probably one of the most powerful combo - 
while not the easiest to get started with.

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

Re: Frameworks

[Bruno Desthuilliers]

Emmanuel Surleau a écrit :

Django : very strong integration, excellent documentation and support,
huge community, really easy to get started with. And possibly a bit more
mature and stable...


One strong point in favour of Django: it follows Python's philosophy of 
"batteries included", and features a large array of plugins. There are also 
numerous other add-ons created by the community.


Also, it has a pretty great administration interface.

It still manages to retain flexibility, but you're basically stuck with 
Django's ORM


You're by no way "stuck" with Django's ORM - you are perfectly free not 
to use it. But then you'll obviously loose quite a lot of useful 
features and 3rd part apps...


(which is OK for simple things) and templating language (which is 
OK as long as you don't need custom tags).


Custom tags are nothing complicated.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Diez B. Roggisch]

> web2py is interesting the author appears to be implying(I could be
> misunderstanding this) that the web2py db ORM is equal to if not
> superior to SQLAlchemy - From
> http://www.web2py.com/AlterEgo/default/show/150

I don't read that out of the post, and it almost certainly is wrong, at
least on a general level. There isn't much above SQLAlchemy regarding
flexibility & power, so while simple cases might be simpler with other
ORMs, they often make more complicated ones impossible.

But again, I don't think that's the claim there.

Diez
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[flebber]

On Oct 20, 3:31 am, Massimo Di Pierro  wrote:
> Hello,
>
> Just to clarify. I did not make any statement about "web2py is  
> superior to SQLAlchemy" since that is somewhat subjective.
> SQLALchemy for example does a much better job at accessing legacy  
> databases. web2py is more limited in that respect and we are working  
> on removing those limitations.
>
> I do believe web2py is easier to use than SQLAlchemy, is faster (but  
> yet I do not know SQLAchemy to optimize it properly) and has many  
> features in common with sqlaclhemy including connection pools, joins,  
> left joins, aggregates, nested selects (I do not know SQLAlchemy well  
> enough to know about advanced features that web2py may be missing).  
> The web2py DAL works on Google App Engine while none of the other ORMs  
> do.
>
> Massimo

So does web2py allow for raw sql if there is an advanced procedure or
query that needs to be performed that is outside the scope of the
web2pr orm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Emmanuel Surleau]

> Django : very strong integration, excellent documentation and support,
> huge community, really easy to get started with. And possibly a bit more
> mature and stable...

One strong point in favour of Django: it follows Python's philosophy of 
"batteries included", and features a large array of plugins. There are also 
numerous other add-ons created by the community.

Also, it has a pretty great administration interface.

It still manages to retain flexibility, but you're basically stuck with 
Django's ORM (which is OK for simple things) and templating language (which is 
OK as long as you don't need custom tags).
 
> Pylons : more loosely coupled (imply: less integration), based on
> "standard" components - which is both a blessing and a curse, specially
> wrt/ documentation -, requires a good knowledge of Python and the HTTP
> protocol to get started with. Very powerful and flexible but this comes
> with a price...

Haven't used Pylons, but the documentation has improved the last few years 
with the Pylons book (http://pylonsbook.com/en/1.0/), while still not being up 
to par with Django's. It has also a methodology for deployment, which Django 
decidedly lacks.

Cheers,

Emm
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Massimo Di Pierro]

Hello,

Just to clarify. I did not make any statement about "web2py is  
superior to SQLAlchemy" since that is somewhat subjective.
SQLALchemy for example does a much better job at accessing legacy  
databases. web2py is more limited in that respect and we are working  
on removing those limitations.


I do believe web2py is easier to use than SQLAlchemy, is faster (but  
yet I do not know SQLAchemy to optimize it properly) and has many  
features in common with sqlaclhemy including connection pools, joins,  
left joins, aggregates, nested selects (I do not know SQLAlchemy well  
enough to know about advanced features that web2py may be missing).  
The web2py DAL works on Google App Engine while none of the other ORMs  
do.



Massimo
--
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[flebber]

On Oct 20, 12:32 am, "Diez B. Roggisch"  wrote:
> > web2py is interesting the author appears to be implying(I could be
> > misunderstanding this) that the web2py db ORM is equal to if not
> > superior to SQLAlchemy - From
> >http://www.web2py.com/AlterEgo/default/show/150
>
> I don't read that out of the post, and it almost certainly is wrong, at
> least on a general level. There isn't much above SQLAlchemy regarding
> flexibility & power, so while simple cases might be simpler with other
> ORMs, they often make more complicated ones impossible.
>
> But again, I don't think that's the claim there.
>
> Diez

That sounds fair.

Bruno posted earlier

> >Django : very strong integration, excellent documentation and support,
>huge community, really easy to get started with. And possibly a bit more
>mature and stable...

>Pylons : more loosely coupled (imply: less integration), based on
>"standard" components - which is both a blessing and a curse, specially
>wrt/ documentation -, requires a good knowledge of Python and the HTTP
>protocol to get started with. Very powerful and flexible but this comes
>with a price...

>Now both are written by talented programmers, and both are pretty good
>tools. I guess it's more a matter of personal preferences and/or
>external constraints (PHB etc...) than anything else.

>A couple other "lightweight" candidates you migh want to consider are
>werkzeug and web.py:

>http://werkzeug.pocoo.org/
>http://webpy.org/

In short it seems to me that Django and Web2py include more "magic" in
assisting oneself to create you web/application, whilst Pylons and
Werkzueg leave more control in the users hands hopefully leading to
greater expression and power.

Pylons recommends SQLALchemy and Mako (offers Genshi and Jinja2) and
Werkzueg SQLAlchemy and Jinja2. As I don't have the experience to tell
the pro's cons of these two apart, would choosing Pylons based on
Documentation be a fair call?

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

Re: Frameworks

[Marco Mariani]

Diez B. Roggisch wrote:


I don't read that out of the post, and it almost certainly is wrong, at
least on a general level. There isn't much above SQLAlchemy regarding
flexibility & power, so while simple cases might be simpler with other
ORMs, they often make more complicated ones impossible.

But again, I don't think that's the claim there.


Both ORMs and others have been described, by their authors, during the 
PyCon in March 2009:


http://us.pycon.org/2009/conference/schedule/event/60/


By the way, this line


in web2py you can access legacy databases if tables have an existing unique 
auto-increment field id and if this field is used for references


is a bit like saying "any color you like as long as it's black" and it's 
not a light limitation. There wouldn't be much of an impedence mismatch 
(*) if a numeric auto-increment primary key was enough for everybody.


Sure SQLAlchemy is more complex to master :-/



(*) 
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx


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

Re: Frameworks

[flebber]

On Oct 19, 10:51 pm, flebber  wrote:
> On Oct 19, 7:40 pm, Javier Santana  wrote:
>
>
>
> > junohttp://github.com/breily/juno
>
> > it's very easy, uses sqlalchemy as ORM and jinja2 (others can be used
> > if you want) for templates.
>
> > On Mon, Oct 19, 2009 at 10:24 AM, Bruno Desthuilliers
>
> >  wrote:
> > > flebber a écrit :
>
> > >> Hi
>
> > >> I have been searching through the vast array of python frameworks
> > >>http://wiki.python.org/moin/WebFrameworksandits quite astounding the
> > >> choice available.
>
> > >> I am looking at using a web framework for my personal project which
> > >> isn't actually aimed at developing a website as such. However I deduce
> > >> that rather than creating a gui application and screen input for data,
> > >> I can use a web browser for this and have a great array of tools to
> > >> format input screens and output display formats.
>
> > > Yeps - but remember that a web app will have a couple limitations /
> > > drawbacks, specially wrt/ handling complex UI.
>
> > >> Since I will be retreiving information from several websites (usually
> > >> csv files) formatting them and submitting them to a database and
> > >> creating queries and printouts based on them most frameworks seem to
> > >> handle this basically with ease and for any complex queries most
> > >> support SqlAlchemy.
>
> > >> Is it simply a case of just picking one and starting and I would find
> > >> it hard to be dissapointed or is there a few special considerations to
> > >> make, though I am unsure what they are?
>
> > > Given your "specs", forget about monstruosities like Zope, Twisted etc, 
> > > that
> > > will mostly get in the way. You have simple needs, use a simple tool !-)
>
> > >> Most obvious ones I am considering are Django (Of course),
>
> > > A pretty good framework, but you'll loose some of it's nice features if 
> > > you
> > > ever want to use an alternate DB layer or templating system. OTHO, most
> > > other more "flexible" frameworks just don't offer this level of 
> > > integration,
> > > so it's may not be such a big deal.
>
> > > Note that Django's ORM, while already pretty good and constently 
> > > improving,
> > > is not as powerful as SLQAlchemy (now nothing prevents you from going down
> > > to raw SQL for the more complex queries - and this might be better anyway,
> > > since complex queries usually requires to be very fine tuned and tend to 
> > > not
> > > be really portable). The Forms API OTHO is a real winner IMHO.
>
> > >> Pylons
> > >> includes SqlAlchemy, Sql Object and templating and I here turbogears
> > >> plans to sit on top of this platform.
>
> > > I admit I fail to see what TG brings except for more indirection levels.
>
> > >> Zope I am considering but I am a
> > >> little confused by this.
>
> > > Friendly advice (based on years of working experience): don't waste your
> > > time with Zope.
>
> > >> The are heaps of others but not sure how to
> > >> narrow the selection criteria.
>
> > >> How/Why woul you split Django and Pylons let alone the others?
>
> > > Django : very strong integration, excellent documentation and support, 
> > > huge
> > > community, really easy to get started with. And possibly a bit more mature
> > > and stable...
>
> > > Pylons : more loosely coupled (imply: less integration), based on 
> > > "standard"
> > > components - which is both a blessing and a curse, specially wrt/
> > > documentation -, requires a good knowledge of Python and the HTTP protocol
> > > to get started with. Very powerful and flexible but this comes with a
> > > price...
>
> > > Now both are written by talented programmers, and both are pretty good
> > > tools. I guess it's more a matter of personal preferences and/or external
> > > constraints (PHB etc...) than anything else.
>
> > > A couple other "lightweight" candidates you migh want to consider are
> > > werkzeug and web.py:
>
> > >http://werkzeug.pocoo.org/
> > >http://webpy.org/
>
> > >> Database likely to be MySQl
>
> > > Mmmm If your application is "write-heavy", PostgreSQL might be a 
> > > better
> > 

Re: Frameworks

[flebber]

On Oct 19, 7:40 pm, Javier Santana  wrote:
> junohttp://github.com/breily/juno
>
> it's very easy, uses sqlalchemy as ORM and jinja2 (others can be used
> if you want) for templates.
>
> On Mon, Oct 19, 2009 at 10:24 AM, Bruno Desthuilliers
>
>  wrote:
> > flebber a écrit :
>
> >> Hi
>
> >> I have been searching through the vast array of python frameworks
> >>http://wiki.python.org/moin/WebFrameworksand its quite astounding the
> >> choice available.
>
> >> I am looking at using a web framework for my personal project which
> >> isn't actually aimed at developing a website as such. However I deduce
> >> that rather than creating a gui application and screen input for data,
> >> I can use a web browser for this and have a great array of tools to
> >> format input screens and output display formats.
>
> > Yeps - but remember that a web app will have a couple limitations /
> > drawbacks, specially wrt/ handling complex UI.
>
> >> Since I will be retreiving information from several websites (usually
> >> csv files) formatting them and submitting them to a database and
> >> creating queries and printouts based on them most frameworks seem to
> >> handle this basically with ease and for any complex queries most
> >> support SqlAlchemy.
>
> >> Is it simply a case of just picking one and starting and I would find
> >> it hard to be dissapointed or is there a few special considerations to
> >> make, though I am unsure what they are?
>
> > Given your "specs", forget about monstruosities like Zope, Twisted etc, that
> > will mostly get in the way. You have simple needs, use a simple tool !-)
>
> >> Most obvious ones I am considering are Django (Of course),
>
> > A pretty good framework, but you'll loose some of it's nice features if you
> > ever want to use an alternate DB layer or templating system. OTHO, most
> > other more "flexible" frameworks just don't offer this level of integration,
> > so it's may not be such a big deal.
>
> > Note that Django's ORM, while already pretty good and constently improving,
> > is not as powerful as SLQAlchemy (now nothing prevents you from going down
> > to raw SQL for the more complex queries - and this might be better anyway,
> > since complex queries usually requires to be very fine tuned and tend to not
> > be really portable). The Forms API OTHO is a real winner IMHO.
>
> >> Pylons
> >> includes SqlAlchemy, Sql Object and templating and I here turbogears
> >> plans to sit on top of this platform.
>
> > I admit I fail to see what TG brings except for more indirection levels.
>
> >> Zope I am considering but I am a
> >> little confused by this.
>
> > Friendly advice (based on years of working experience): don't waste your
> > time with Zope.
>
> >> The are heaps of others but not sure how to
> >> narrow the selection criteria.
>
> >> How/Why woul you split Django and Pylons let alone the others?
>
> > Django : very strong integration, excellent documentation and support, huge
> > community, really easy to get started with. And possibly a bit more mature
> > and stable...
>
> > Pylons : more loosely coupled (imply: less integration), based on "standard"
> > components - which is both a blessing and a curse, specially wrt/
> > documentation -, requires a good knowledge of Python and the HTTP protocol
> > to get started with. Very powerful and flexible but this comes with a
> > price...
>
> > Now both are written by talented programmers, and both are pretty good
> > tools. I guess it's more a matter of personal preferences and/or external
> > constraints (PHB etc...) than anything else.
>
> > A couple other "lightweight" candidates you migh want to consider are
> > werkzeug and web.py:
>
> >http://werkzeug.pocoo.org/
> >http://webpy.org/
>
> >> Database likely to be MySQl
>
> > Mmmm If your application is "write-heavy", PostgreSQL might be a better
> > choice. Anyway, both Django's ORM and SQLAlchemy work fine with MySQL
> > AFAICT.
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
>

After further reading Django does indeed cover a lot of bases. When
looking at jinja2 and werkzueg, first thing I noticed is that they are
by the same group called pocoo. Second it shows that I must be
misunderstanding something, can I really use jinja2 and sqlAlchemy by
itself? The werkzeug documentation shows a screencast 
http://werkzeug.pocoo.org/wiki30/
of making a wiki and uses werkzueg, jinja2 and sqlAlchemy, why
werkzueg and jinja2 in combination?

And pylons advises use of SqlAlchemy and Mako or choices of Genshi and
Jinja2, so what is pylons adding? Might have to do a bit more reading
and watch a few more screencasts :-)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Javier Santana]

juno
http://github.com/breily/juno

it's very easy, uses sqlalchemy as ORM and jinja2 (others can be used
if you want) for templates.

On Mon, Oct 19, 2009 at 10:24 AM, Bruno Desthuilliers
 wrote:
> flebber a écrit :
>>
>> Hi
>>
>> I have been searching through the vast array of python frameworks
>> http://wiki.python.org/moin/WebFrameworks and its quite astounding the
>> choice available.
>>
>> I am looking at using a web framework for my personal project which
>> isn't actually aimed at developing a website as such. However I deduce
>> that rather than creating a gui application and screen input for data,
>> I can use a web browser for this and have a great array of tools to
>> format input screens and output display formats.
>
> Yeps - but remember that a web app will have a couple limitations /
> drawbacks, specially wrt/ handling complex UI.
>
>> Since I will be retreiving information from several websites (usually
>> csv files) formatting them and submitting them to a database and
>> creating queries and printouts based on them most frameworks seem to
>> handle this basically with ease and for any complex queries most
>> support SqlAlchemy.
>>
>> Is it simply a case of just picking one and starting and I would find
>> it hard to be dissapointed or is there a few special considerations to
>> make, though I am unsure what they are?
>
> Given your "specs", forget about monstruosities like Zope, Twisted etc, that
> will mostly get in the way. You have simple needs, use a simple tool !-)
>
>> Most obvious ones I am considering are Django (Of course),
>
> A pretty good framework, but you'll loose some of it's nice features if you
> ever want to use an alternate DB layer or templating system. OTHO, most
> other more "flexible" frameworks just don't offer this level of integration,
> so it's may not be such a big deal.
>
> Note that Django's ORM, while already pretty good and constently improving,
> is not as powerful as SLQAlchemy (now nothing prevents you from going down
> to raw SQL for the more complex queries - and this might be better anyway,
> since complex queries usually requires to be very fine tuned and tend to not
> be really portable). The Forms API OTHO is a real winner IMHO.
>
>> Pylons
>> includes SqlAlchemy, Sql Object and templating and I here turbogears
>> plans to sit on top of this platform.
>
> I admit I fail to see what TG brings except for more indirection levels.
>
>> Zope I am considering but I am a
>> little confused by this.
>
> Friendly advice (based on years of working experience): don't waste your
> time with Zope.
>
>> The are heaps of others but not sure how to
>> narrow the selection criteria.
>>
>> How/Why woul you split Django and Pylons let alone the others?
>
> Django : very strong integration, excellent documentation and support, huge
> community, really easy to get started with. And possibly a bit more mature
> and stable...
>
> Pylons : more loosely coupled (imply: less integration), based on "standard"
> components - which is both a blessing and a curse, specially wrt/
> documentation -, requires a good knowledge of Python and the HTTP protocol
> to get started with. Very powerful and flexible but this comes with a
> price...
>
> Now both are written by talented programmers, and both are pretty good
> tools. I guess it's more a matter of personal preferences and/or external
> constraints (PHB etc...) than anything else.
>
> A couple other "lightweight" candidates you migh want to consider are
> werkzeug and web.py:
>
> http://werkzeug.pocoo.org/
> http://webpy.org/
>
>> Database likely to be MySQl
>
> Mmmm If your application is "write-heavy", PostgreSQL might be a better
> choice. Anyway, both Django's ORM and SQLAlchemy work fine with MySQL
> AFAICT.
> --
> http://mail.python.org/mailman/listinfo/python-list
>
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Frameworks

[Bruno Desthuilliers]

flebber a écrit :

Hi

I have been searching through the vast array of python frameworks
http://wiki.python.org/moin/WebFrameworks and its quite astounding the
choice available.

I am looking at using a web framework for my personal project which
isn't actually aimed at developing a website as such. However I deduce
that rather than creating a gui application and screen input for data,
I can use a web browser for this and have a great array of tools to
format input screens and output display formats.


Yeps - but remember that a web app will have a couple limitations / 
drawbacks, specially wrt/ handling complex UI.



Since I will be retreiving information from several websites (usually
csv files) formatting them and submitting them to a database and
creating queries and printouts based on them most frameworks seem to
handle this basically with ease and for any complex queries most
support SqlAlchemy.

Is it simply a case of just picking one and starting and I would find
it hard to be dissapointed or is there a few special considerations to
make, though I am unsure what they are?


Given your "specs", forget about monstruosities like Zope, Twisted etc, 
that will mostly get in the way. You have simple needs, use a simple 
tool !-)



Most obvious ones I am considering are Django (Of course),


A pretty good framework, but you'll loose some of it's nice features if 
you ever want to use an alternate DB layer or templating system. OTHO, 
most other more "flexible" frameworks just don't offer this level of 
integration, so it's may not be such a big deal.


Note that Django's ORM, while already pretty good and constently 
improving, is not as powerful as SLQAlchemy (now nothing prevents you 
from going down to raw SQL for the more complex queries - and this might 
be better anyway, since complex queries usually requires to be very fine 
tuned and tend to not be really portable). The Forms API OTHO is a real 
winner IMHO.



Pylons
includes SqlAlchemy, Sql Object and templating and I here turbogears
plans to sit on top of this platform.


I admit I fail to see what TG brings except for more indirection levels.


Zope I am considering but I am a
little confused by this.


Friendly advice (based on years of working experience): don't waste your 
time with Zope.



The are heaps of others but not sure how to
narrow the selection criteria.

How/Why woul you split Django and Pylons let alone the others?


Django : very strong integration, excellent documentation and support, 
huge community, really easy to get started with. And possibly a bit more 
mature and stable...


Pylons : more loosely coupled (imply: less integration), based on 
"standard" components - which is both a blessing and a curse, specially 
wrt/ documentation -, requires a good knowledge of Python and the HTTP 
protocol to get started with. Very powerful and flexible but this comes 
with a price...


Now both are written by talented programmers, and both are pretty good 
tools. I guess it's more a matter of personal preferences and/or 
external constraints (PHB etc...) than anything else.


A couple other "lightweight" candidates you migh want to consider are 
werkzeug and web.py:


http://werkzeug.pocoo.org/
http://webpy.org/


Database likely to be MySQl


Mmmm If your application is "write-heavy", PostgreSQL might be a 
better choice. Anyway, both Django's ORM and SQLAlchemy work fine with 
MySQL AFAICT.

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

Re: Frameworks

[flebber]

On Oct 19, 10:01 am, flebber  wrote:
> Hi
>
> I have been searching through the vast array of python 
> frameworkshttp://wiki.python.org/moin/WebFrameworksand its quite astounding 
> the
> choice available.
>
> I am looking at using a web framework for my personal project which
> isn't actually aimed at developing a website as such. However I deduce
> that rather than creating a gui application and screen input for data,
> I can use a web browser for this and have a great array of tools to
> format input screens and output display formats.
>
> Since I will be retreiving information from several websites (usually
> csv files) formatting them and submitting them to a database and
> creating queries and printouts based on them most frameworks seem to
> handle this basically with ease and for any complex queries most
> support SqlAlchemy.
>
> Is it simply a case of just picking one and starting and I would find
> it hard to be dissapointed or is there a few special considerations to
> make, though I am unsure what they are?
>
> Most obvious ones I am considering are Django (Of course), Pylons
> includes SqlAlchemy, Sql Object and templating and I here turbogears
> plans to sit on top of this platform. Zope I am considering but I am a
> little confused by this. The are heaps of others but not sure how to
> narrow the selection criteria.
>
> How/Why woul you split Django and Pylons let alone the others?
>
> Database likely to be MySQl

I guess what makes it so interesting is that there appear to be so man
high quality options. Its astounding.
-- 
http://mail.python.org/mailman/listinfo/python-list

Frameworks

[flebber]

Hi

I have been searching through the vast array of python frameworks
http://wiki.python.org/moin/WebFrameworks and its quite astounding the
choice available.

I am looking at using a web framework for my personal project which
isn't actually aimed at developing a website as such. However I deduce
that rather than creating a gui application and screen input for data,
I can use a web browser for this and have a great array of tools to
format input screens and output display formats.

Since I will be retreiving information from several websites (usually
csv files) formatting them and submitting them to a database and
creating queries and printouts based on them most frameworks seem to
handle this basically with ease and for any complex queries most
support SqlAlchemy.

Is it simply a case of just picking one and starting and I would find
it hard to be dissapointed or is there a few special considerations to
make, though I am unsure what they are?

Most obvious ones I am considering are Django (Of course), Pylons
includes SqlAlchemy, Sql Object and templating and I here turbogears
plans to sit on top of this platform. Zope I am considering but I am a
little confused by this. The are heaps of others but not sure how to
narrow the selection criteria.

How/Why woul you split Django and Pylons let alone the others?

Database likely to be MySQl
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: web frameworks that support Python 3

[Graham Dumpleton]

On Aug 26, 12:19 pm, exar...@twistedmatrix.com wrote:
> On 01:41 am, a...@pythoncraft.com wrote:
>
>
>
>
>
> >In article
> >,
> >Graham Dumpleton   wrote:
> >>On Aug 24, 6:34=A0am, Sebastian Wiesner  wrote:
>
> >>>In any case, there is bottle [1], which provides a *very minimal*
> >>>framewo=
> >>rk
> >>>for WSGI web development. =A0Don't expect too much, it is really
> >>>small, a=
> >>nd
> >>>doesn't do much more than routing and minimal templating.
>
> >>>However, it is the only Python-3-compatible web framework I know of.
>
> >>>[1]http://bottle.paws.de/page/start
>
> >>There is one big flaw with your claim. That is the there is no WSGI
> >>specification for Python 3.0 as yet. Anything that claims to work with
> >>WSGI and Python 3.0 is just a big guess as far as how WSGI for Python
> >>3.0 may work.
>
> >Perhaps you meant "library" instead of "specification"?
>
> He meant specification.
>
> Python 3.x is different enough from any Python 2.x release that PEP 333
> no longer completely makes sense.  It needs to be modified to be
> applicable to Python 3.x.
>
> So, in the sense that there is no written down, generally agreed upon
> specification for what WSGI on Python 3.x means, there is no...
> specification.
>
> There is, however, apparently, a library. ;)

If you are talking about wsgiref then that was somewhat broken in
Python 3.0. In Python 3.1 it works for some definition of works. The
problem again being that since WSGI specification hasn't been updated
for Python 3.X, that how it works will likely not match what the
specification may eventually say. This will become more and more of a
problem if WSGI specification isn't updated. At the moment the
discussion is going around in circles, although, if I put my
optimistic face on, I would say it is a slow inward spiral. Not quite
a death spiral at least.

Graham
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: web frameworks that support Python 3

[exarkun]

On 01:41 am, a...@pythoncraft.com wrote:
In article 
,

Graham Dumpleton   wrote:

On Aug 24, 6:34=A0am, Sebastian Wiesner  wrote:


In any case, there is bottle [1], which provides a *very minimal* 
framewo=

rk
for WSGI web development. =A0Don't expect too much, it is really 
small, a=

nd

doesn't do much more than routing and minimal templating.

However, it is the only Python-3-compatible web framework I know of.

[1]http://bottle.paws.de/page/start


There is one big flaw with your claim. That is the there is no WSGI
specification for Python 3.0 as yet. Anything that claims to work with
WSGI and Python 3.0 is just a big guess as far as how WSGI for Python
3.0 may work.


Perhaps you meant "library" instead of "specification"?


He meant specification.

Python 3.x is different enough from any Python 2.x release that PEP 333 
no longer completely makes sense.  It needs to be modified to be 
applicable to Python 3.x.


So, in the sense that there is no written down, generally agreed upon 
specification for what WSGI on Python 3.x means, there is no... 
specification.


There is, however, apparently, a library. ;)

Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list

Re: web frameworks that support Python 3

[Aahz]

In article ,
Graham Dumpleton   wrote:
>On Aug 24, 6:34=A0am, Sebastian Wiesner  wrote:
>> 
>> In any case, there is bottle [1], which provides a *very minimal* framewo=
>rk
>> for WSGI web development. =A0Don't expect too much, it is really small, a=
>nd
>> doesn't do much more than routing and minimal templating.
>>
>> However, it is the only Python-3-compatible web framework I know of.
>>
>> [1]http://bottle.paws.de/page/start
>
>There is one big flaw with your claim. That is the there is no WSGI
>specification for Python 3.0 as yet. Anything that claims to work with
>WSGI and Python 3.0 is just a big guess as far as how WSGI for Python
>3.0 may work.

Perhaps you meant "library" instead of "specification"?  I don't
understand how a language can be missing a specification.
-- 
Aahz (a...@pythoncraft.com)   <*> http://www.pythoncraft.com/

"I support family values -- Addams family values" --www.nancybuttons.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: web frameworks that support Python 3

[Nobody]

On Sun, 23 Aug 2009 16:32:09 -0400, Albert Hopkins wrote:

> What's different about Python 3 is that there is only unicode strings,
> whereas Python 2 has a string type and a unicode type.

Python 2 has "str" (char) and "unicode" (wchar) types.

Python 3 has "bytes" (char) and "str" (wchar) types.

The main difference is that Python 3 uses unicode "by default", i.e.
string literals are unicode rather than byte strings, variables
such as sys.argv and os.environ contain unicode strings, etc.

There are other differences, e.g.:

+ Passing a "bytes" object where "str" is expected will raise an exception
rather than using an automatic conversion
+ Subscripting a "bytes" object returns an integer between 0 and 255
+ upper(), isalpha(), etc assume ASCII rather than the system encoding

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

Re: web frameworks that support Python 3

[Graham Dumpleton]

On Aug 24, 6:34 am, Sebastian Wiesner  wrote:
> At Sunday 23 August 2009 22:13:16 you wrote:> I use Chinese and therefore 
> Unicode very heavily, and so Python 3 is
> > an unavoidable choice for me.
>
> Python 2.x supports Unicode just as well as Python 3.  Every common web
> framework works perfectly with unicode.
>
> In any case, there is bottle [1], which provides a *very minimal* framework
> for WSGI web development.  Don't expect too much, it is really small, and
> doesn't do much more than routing and minimal templating.
>
> However, it is the only Python-3-compatible web framework I know of.
>
> [1]http://bottle.paws.de/page/start

There is one big flaw with your claim. That is the there is no WSGI
specification for Python 3.0 as yet. Anything that claims to work with
WSGI and Python 3.0 is just a big guess as far as how WSGI for Python
3.0 may work.

I would therefore be a bit cautious with your claim.

Graham

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