wheezy projects update
All libraries related wheezy.web<https://github.com/akornatskyy/wheezy.web> and wheezy.template<https://github.com/akornatskyy/wheezy.template> have been recently migrated from bitbucket to github<https://github.com/akornatskyy>. As a part of this migration there have been provided the following major benefits: * Established build process with travis-ci * Dependecy updates with dependabot * Integrated with covereall.io, 100% test coverage * Release process to pypi per tags with github actions * Replaced Makefile with tox, covering python 2.7, 3.7+, pypy3 * Improved linting with autoflake, flake8, flake8-bugbear, flake8-import-order, flake8-mutable, pep8-naming * Code formatting with black and isort * Eliminated beta status * Benchmarks have been migrated to py-helloworld<https://github.com/akornatskyy/py-helloworld> and scheduled to run on travis.ci<https://travis-ci.org/github/akornatskyy/py-helloworld> weekly with py3, py3-cython and pypy3 Plans: * Support for python2.7 will be dropped in 2021 * Major cleanup from python 2.4-2.7 compatibility code * Update to use mypy in strict mode If you’re using some of these libraries, ★Star a related repository to show your interest, please! Thanks. Andriy Kornatskyy ___ Python-announce-list mailing list -- python-announce-list@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Member address: arch...@mail-archive.com
Re: Question about Source Control
Frank, I would suggest start with an account on https://bitbucket.org. It supports private repositories so you should be good there. From other hand you can setup own infrastructure for SCM, read more here: http://mindref.blogspot.com/2013/10/how-to-manage-git-or-mercurial.html Thanks. Andriy Kornatskyy On Mar 17, 2014, at 3:06 PM, Frank Millman fr...@chagford.com wrote: Hi all I know I *should* be using a Source Control Management system, but at present I am not. I tried to set up Mercurial a couple of years ago, but I think I set it up wrongly, as I got myself confused and found it more of a hindrance than a help. Now I am ready to try again, but I want to avoid my earlier mistakes. I understand the concept, and I understand the importance, so I do not need reminding of those. What I would like help with is the basic setup. I could subscribe to the Mercurial mailing list and ask there, but I am hoping for a kick-start here. Here is my setup. All my source code resides on an old Linux server, which I switch on in the morning and switch off at night, but otherwise hardly ever look at. It uses 'samba' to allow sharing with Windows, and 'nfs' to allow sharing with other Linux machines. I need to test my program on Windows and on Linux, so I run it from both at various times. On Windows I have a 'mapped drive' pointing to the source code. On Linux I use a third machine, running a recent Fedora, using nfs to mount a directory pointing to the source code. Obviously each machine has its own version of Python installed. I do my development on the Windows machine. I use TextPad, a simple text editor, which works fine for my purposes. It uses the mapped drive to point to the source code. So where should I install the SCM, and how should I set it up so that I can access the latest version from any machine? Any hints will be appreciated. Frank Millman -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: SMTPHandler and mail subject
Eras, You have to override getSubject method of SMTPHandler. http://hg.python.org/cpython/file/677327810121/Lib/logging/handlers.py#l907 Thanks. Andriy Kornatskyy On Mar 12, 2014, at 12:08 PM, eras.rasmu...@gmail.com wrote: Hi I use logging.handlers.SMTPHandler and i have tried to change subject of mail. Are there exists easy way to do that ? Subject of mail can change repeatedly depends on content of mail. Eras -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Wheezy.web - is it been developed?
Marcio, The existence of forum site / mailing list does not guarantee your problem will be solved. The bitbucket.org doesn’t offer mailing list feature, however you can subscribe to any changes happening by following me or concrete project there. The specific issues can be tracked down to commit via issues list. What relates to mailing list… I have sent request to google groups to allow dot in name, however there was no reply yet. I suppose that might take a week to hear something back from them. Anyway, should you have any specific questions please use this mailing list or contact me directly. I will be happy to answer in either case. Thanks. Andriy Kornatskyy On Feb 22, 2014, at 11:48 PM, milos2...@gmail.com wrote: Let's open a group for Wheezy.web. I'm just wondering which forum site to choose? Any suggestions? -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Wheezy.web - is it been developed?
Chris, Your comments are very valuable. I didn’t find any free mailman lists, so it appears google groups is the only option. Thanks. Andriy Kornatskyy On Feb 23, 2014, at 12:30 AM, Chris Angelico ros...@gmail.com wrote: On Sun, Feb 23, 2014 at 8:48 AM, milos2...@gmail.com wrote: Let's open a group for Wheezy.web. I'm just wondering which forum site to choose? Any suggestions? If you want to discuss something serious, use a Mailman list. Everywhere I go, Mailman lists have high signal-to-noise ratios, higher than pretty much everything else I know. (And most of the problems on python-list come from the newsgroup side. Google Groups's messes, a lot of the spam, it's all from comp.lang.python rather than python-list.) Use a web forum like PHPBB or VBulletin if you think you need to; a Facebook or G+ group if you want inanity; a weekly get-together if you want tea; but a Mailman list if you want solid content. ChrisA -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Mac vs. Linux for Python Development
I used to do core python development using debian linux (gnome). All way long work just fine. However recently I have had a chance to try MacOS X 10.8 and later 10.9. I used macports.org to setup everything I found “missing”. Vim works fine regardless the platform… quite happy. Thanks. Andriy Kornatskyy On Feb 23, 2014, at 10:43 AM, twiz twiza...@gmail.com wrote: Hello, I'm sure this is a common question but I can't seem to find a previous thread that addresses it. If one one exists, please point me to it. I've been developing with python recreationally for a while on Ubuntu but will soon be transitioning to full-time python development. I have the option of using a Mac or Ubuntu environment and I'd like to hear any thoughts on the pros and cons of each. Specifically, how's the support for numpy and scipy? How are the IDEs? Since I generally like working with a Mac, I'd like to hear if there are any significant downsides to python dev on OsX. Thanks -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Wheezy.web - is it been developed?
Marcio, The wheezy.web framework (http://bitbucket.org/akorn/wheezy.web) supplies documentation, tutorials, quick starts and benchmark for you. Due to modular architecture, it is being developed in several independent loosely coupled libraries under wheezy.*. The source code is easy to read, there is 100% test coverage. No bells and whistles. I believe the web framework should not be something cryptic (requiring community to exchange ideas about workarounds) nor something that involves infinitive development cycle. If you have any questions I will be happy to answer in this mailing list or personally. Thanks. Andriy Kornatskyy On Feb 19, 2014, at 1:48 AM, Marcio Andrey Oliveira plicat...@gmail.com wrote: Hi. I stumbled upon Wheezy.web and I got interested into learn more about it. After googling I didn't find that many information about it: only docs and samples from its web site. I didn't find a mailing list nor user groups and no tutorials from its users. Is Wheezy.web been actively developed? Does it have any user base community that I could get in touch with? Or should I forget about it and stick to say flask or pyramid? Thank you. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: How to get Mac address of ethernet port?
Sam, How about this? from uuid import getnode as get_mac '%012x' % get_mac() Thanks. Andriy Kornatskyy On Jan 11, 2014, at 4:26 PM, Sam lightai...@gmail.com wrote: I would like to use python to retrieve the mac address of the ethernet port. Can this be done? Thank you. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
How to manage Git or Mercurial repositories
Managing version control repositories can be a challenge in multi-user environment especially when simplification of user collaboration is your goal. There are usually two primary concerns while considering enterprise deployment for version control repositories: access control and safety of your data. Both are not directly addressed by version control itself, thus a sort of security facade is necessary. Read more here: http://mindref.blogspot.com/2013/10/how-to-manage-git-or-mercurial.html Thanks. Andriy Kornatskyy -- https://mail.python.org/mailman/listinfo/python-list
RE: How much memory does Django consume compared to Rails?
A memory consumption by python web frameworks is relatively low. A `typical` web site developed using wheezy.web (a lightweight full-featured web framework) consumes about 14-23 Mb per worker on x86 platform. The django is not far from there. A minimal django hello world application hosted in uWSGI application server: 11Mb master + N * 9.4Mb per worker Andriy Date: Wed, 19 Jun 2013 09:18:11 -0700 Subject: How much memory does Django consume compared to Rails? From: jhsu802...@gmail.com To: python-list@python.org I have deployed two Ruby on Rails sites on WebFaction, and Passenger Rack takes up around 60 MB of memory apiece. I was planning on replacing my Drupal web sites with Rails, but I'm now considering replacing these Drupal sites with Django. Given that the baseline memory consumption for a Rails site is around 60 MB, how would a Django site compare? -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: String performance regression from python 3.2 to 3.3
$ python3.2 Python 3.2.3 (default, Jun 25 2012, 22:55:05) [GCC 4.6.3] on linux2 Type help, copyright, credits or license for more information. from timeit import repeat repeat(s=s[:-1]+'\u0034',s='asdf'*1,number=1) [0.2566258907318115, 0.14485502243041992, 0.14464998245239258] repeat(s=s[:-1]+'\u1234',s='asdf'*1,number=1) [0.25584888458251953, 0.1340939998626709, 0.1338820457458496] repeat(s=s[:-1]+'\u1234',s='\u1234sdf'*1,number=1) [0.2571289539337158, 0.13403892517089844, 0.13388800621032715] repeat(s=s[:-1]+'\U00012345',s='asdf'*1,number=1) [0.5022759437561035, 0.3970041275024414, 0.3764481544494629] repeat(s=s[:-1]+'\U00012345',s='\u1234sdf'*1,number=1) [0.5213770866394043, 0.38585615158081055, 0.40251588821411133] repeat(s=s[:-1]+'\U00012345',s='\U00012345sdf'*1,number=1) [0.768744945526123, 0.5852570533752441, 0.6029140949249268] $ python3.3 Python 3.3.0 (default, Sep 29 2012, 15:35:49) [GCC 4.7.1] on linux Type help, copyright, credits or license for more information. from timeit import repeat repeat(s=s[:-1]+'\u0034',s='asdf'*1,number=1) [0.0985728640225716, 0.0984080360212829, 0.07457763599813916] repeat(s=s[:-1]+'\u1234',s='asdf'*1,number=1) [0.901988381985575, 0.7517840950167738, 0.7540924890199676] repeat(s=s[:-1]+'\u1234',s='\u1234sdf'*1,number=1) [0.3069786810083315, 0.17701858800137416, 0.1769046070112381] repeat(s=s[:-1]+'\U00012345',s='asdf'*1,number=1) [1.081760977016529, 0.9099628589756321, 0.9926943230093457] repeat(s=s[:-1]+'\U00012345',s='\u1234sdf'*1,number=1) [1.2101859120011795, 1.1039280130062252, 0.9306247030035593] repeat(s=s[:-1]+'\U00012345',s='\U00012345sdf'*1,number=1) [0.4759294819959905, 0.35435649199644104, 0.3540659479913302] Date: Fri, 15 Mar 2013 10:07:48 -0700 Subject: Re: String performance regression from python 3.2 to 3.3 From: rustompm...@gmail.com To: python-list@python.org 3.2 and 2.7 results on my desktop using Chris examples (Hope I cut-pasted them correctly) - Welcome to the Emacs shell ~ $ python3 Python 3.2.3 (default, Feb 20 2013, 17:02:41) [GCC 4.7.2] on linux2 Type help, copyright, credits or license for more information. from timeit import timeit timeit(s=s[:-1]+'\u0034',s='asdf'*1,number=1) 0.2893378734588623 timeit(s=s[:-1]+'\u1234',s='asdf'*1,number=1) 0.2842249870300293 timeit(s=s[:-1]+'\u1234',s='\u1234sdf'*1,number=1) 0.28406381607055664 timeit(s=s[:-1]+'\U00012345',s='asdf'*1,number=1) 0.28420209884643555 timeit(s=s[:-1]+'\U00012345',s='\u1234sdf'*1,number=1) 0.2853250503540039 timeit(s=s[:-1]+'\U00012345',s='\U00012345sdf'*1,number=1) 0.283905029296875 ~ $ python Python 2.7.3 (default, Jan 2 2013, 16:53:07) [GCC 4.7.2] on linux2 Type help, copyright, credits or license for more information. from timeit import timeit timeit(s=s[:-1]+'\u0034',s='asdf'*1,number=1) 0.20418286323547363 timeit(s=s[:-1]+'\u1234',s='asdf'*1,number=1) 0.20579099655151367 timeit(s=s[:-1]+'\u1234',s='\u1234sdf'*1,number=1) 0.5055279731750488 timeit(s=s[:-1]+'\U00012345',s='asdf'*1,number=1) 0.28449511528015137 timeit(s=s[:-1]+'\U00012345',s='\u1234sdf'*1,number=1) 0.6001529693603516 timeit(s=s[:-1]+'\U00012345',s='\U00012345sdf'*1,number=1) 0.8430721759796143 -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Twisted or Tornado?
Jake, Don't you lock yourself in twisted application server only? I doubt you will be able easily migrate to WSGI compatible application server as your needs grow. Andriy From: jake.ang...@gmail.com Date: Mon, 4 Mar 2013 10:35:41 +1100 Subject: Re: Twisted or Tornado? To: andriy.kornats...@live.com CC: sven...@gmail.com; python-list@python.org All, Thanks for your reply - I thought I would share the outcome of my choice: I have chosen to use twisted. The API is very decent to learn, though the clincher is theres huge community / docs, and many projects used on production. I was able to make a working project prototype in hours! Thanks to the large twisted library. Our project is an ipad multiplayer game, and we didnt want to use existing servers because we want to do things exactly as we wish. Rgds, Jake On Fri, Mar 1, 2013 at 8:55 PM, Andriy Kornatskyy andriy.kornats...@live.commailto:andriy.kornats...@live.com wrote: The following benchmarks are related to: a) python web frameworks 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 b) template engines http://mindref.blogspot.com/2012/10/python-templates-benchmark.html http://mindref.blogspot.com/2012/07/python-fastest-template.html With source code: https://bitbucket.org/akorn/helloworld Thanks. Andriy Kornatskyy Date: Fri, 1 Mar 2013 09:25:43 + Subject: Re: Twisted or Tornado? From: sven...@gmail.commailto:sven...@gmail.com To: jake.ang...@gmail.commailto:jake.ang...@gmail.com CC: python-list@python.orgmailto:python-list@python.org Although these articles are a _little_ old they are probably useful to help you decide which solution is most suitable for you in terms of performance http://nichol.as/benchmark-of-python-web-servers http://nichol.as/asynchronous-servers-in-python I would also be interested if any one on this list has any idea if the results above would be any different these days or whether the benchmarks are still fairly representative. On 1 March 2013 00:28, Jake Angulo jake.ang...@gmail.commailto:jake.ang...@gmail.commailto:jake.ang...@gmail.commailto:jake.ang...@gmail.com wrote: I have to say it first: I am not trolling :P Im working on a server project (with IOS client) and would like to create a custom, lean and mean server - real Quick! My requirements for this framework in descending order: 1) Easy to use API 2) Widely available documentation / Examples / Community contributions 3) Feature-wise - kinda most that you commonly need is there Your opinions will be valuable, if possible cite examples or URL references, Pls! I prefer opinion from those who have programmed real projects in it - not just read some blog or Slashdot :P -- http://mail.python.org/mailman/listinfo/python-list -- ./Sven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Twisted or Tornado?
The following benchmarks are related to: a) python web frameworks 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 b) template engines http://mindref.blogspot.com/2012/10/python-templates-benchmark.html http://mindref.blogspot.com/2012/07/python-fastest-template.html With source code: https://bitbucket.org/akorn/helloworld Thanks. Andriy Kornatskyy Date: Fri, 1 Mar 2013 09:25:43 + Subject: Re: Twisted or Tornado? From: sven...@gmail.com To: jake.ang...@gmail.com CC: python-list@python.org Although these articles are a _little_ old they are probably useful to help you decide which solution is most suitable for you in terms of performance http://nichol.as/benchmark-of-python-web-servers http://nichol.as/asynchronous-servers-in-python I would also be interested if any one on this list has any idea if the results above would be any different these days or whether the benchmarks are still fairly representative. On 1 March 2013 00:28, Jake Angulo jake.ang...@gmail.commailto:jake.ang...@gmail.com wrote: I have to say it first: I am not trolling :P Im working on a server project (with IOS client) and would like to create a custom, lean and mean server - real Quick! My requirements for this framework in descending order: 1) Easy to use API 2) Widely available documentation / Examples / Community contributions 3) Feature-wise - kinda most that you commonly need is there Your opinions will be valuable, if possible cite examples or URL references, Pls! I prefer opinion from those who have programmed real projects in it - not just read some blog or Slashdot :P -- http://mail.python.org/mailman/listinfo/python-list -- ./Sven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Project Based python tutorials
I would advise try answer the question: what is my goal? Don't be surprised that not everyone become a programmer... many people fail and get back to market thinking it was waste of time. Thanks. Andriy Kornatskyy Date: Wed, 27 Feb 2013 00:31:11 -0800 Subject: Project Based python tutorials From: alvin.gho...@gmail.com To: python-list@python.org Hi everyone! First of all: Im new to this group and i dont know if there are any rules or jargon around her. If so; pleas fill me in. So, I desided to start learning programming a few months ago and by now i feel pretty confident about the basics of the python language, and programming in general. Variables,loops, conditionals, data structures, methods and even some object oriented programming, are all familiar consepts. As i want to become a better programmer, i figured the next step would be to start working on some bigger and more complex projects.Yet despite my numerouse web searchs for project based tutorials,i cant seem to find any good ones. I have no trouble with understanding the concepts of programming, however I find it quite difficult to take it to the next level. So, is there anyone out there willing to share some experience? I would be really grateful! Greetings from Norway! -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Nuitka now supports Python 3.2
Steven, Just in case... pypy1.9 runs this test 22x faster than cpython2.7, see below. python2.7 -c from test import pystone;[pystone.main() for i in range(10)] Pystone(1.1) time for 5 passes = 0.62 This machine benchmarks at 80645.2 pystones/second ... Pystone(1.1) time for 5 passes = 0.53 This machine benchmarks at 94339.6 pystones/second pypy-1.9/bin/pypy -c from test import pystone;[pystone.main() for i in range(10)] Pystone(1.1) time for 5 passes = 0.116008 This machine benchmarks at 431005 pystones/second ... Pystone(1.1) time for 5 passes = 0.024002 This machine benchmarks at 2.08316e+06 pystones/second Thanks. Andriy Kornatskyy From: steve+comp.lang.pyt...@pearwood.info Subject: Nuitka now supports Python 3.2 Date: Tue, 26 Feb 2013 12:18:56 + To: python-list@python.org Nuitka now supports Python 3.2 syntax and compiles the full CPython 3.2 test suite. http://nuitka.net/posts/nuitka-release-040.html What is Nuitka? Nuitka is an implementation of Python written in C++. At the moment it is claimed to be about 2.5 times as fast as CPython running the pystone benchmark. Future plans including using type inference and whole program analysis to optimize Python code using C++ native types. Unlike PyPy, which is a JIT compiler, Nuitka is intended as a static optimizing compiler. -- Steven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Thoughts on SQL vs ORM
The question of persistence implementation arise often. I found repository pattern very valuable due to separation of concerns, mediate between domain model and data source (mock, file, database, web service, etc). The database data source is somewhat specific since you can proceed with SQL functions or ORM. Here are some thoughts why you might prefer SQL functions over ORM in your next project: http://mindref.blogspot.com/2013/02/sql-vs-orm.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest template engine
Per community request I have added tenjin to the templates benchmark and updated with latest version of other template engines. Just in case here is a link: http://mindref.blogspot.com/2012/10/python-templates-benchmark.html Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: python-list@python.org Subject: RE: Fastest template engine Date: Tue, 23 Oct 2012 15:45:56 +0300 Python template engines offer high reusability of markup code and the following features are used by content developers most of the time: * Includes: useful to incorporate some snippets of content that in most cases are common to the site, e.g. footer, scripts, styles, etc. * Extends: useful to define a master layout for the majority of the site content with placeholders, e.g. sidebar, horizontal menu, content, etc. The content developers extend the master layout by substituting available placeholders. * Widgets: usually small snippets of highly reusable markup, e.g. list item, button, etc. The content developers use widgets to increase readability and enforce consistency of design. All mentioned features above are examined for various template engines (django, jinja2, mako, tornado and wheezy.template) in the following post: http://mindref.blogspot.com/2012/10/python-templates-benchmark.html The test is executed in isolated environment using CPython 2.7 but can be run for Python 3.3 and/or PyPy 1.9. Source code is here: https://bitbucket.org/akorn/helloworld Comments or suggestions are welcome. Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: RE: Fastest template engine Date: Fri, 19 Oct 2012 11:34:41 +0300 Per community request cheetah has been added to benchmark. Post updated, just in case: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: RE: Fastest template engine Date: Wed, 26 Sep 2012 16:21:21 +0300 The post has been updated with the following template engines added (per community request): 1. chameleon 2. django 3. web2py Here is a link: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest template engine Date: Sun, 23 Sep 2012 12:24:36 +0300 I have run recently a benchmark of a trivial 'big table' example for various python template engines (jinja2, mako, tenjin, tornado and wheezy.template) run on cpython2.7 and pypy1.9.. you might find it interesting: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
How to ship eggs with pyo files only
There is sometimes a need to ship python egg distribution with pyo files only. There is confusion using bdist_egg command since it doesn't have any options to do that; you can read more about solution here: http://mindref.blogspot.com/2012/11/python-egg-pyo.html Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list
RE: Web Frameworks Excessive Complexity
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
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
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
andriy.kornats...@live.com 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
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
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
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
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 andriy.kornats...@live.com 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: Python Web Routing Benchmark
Web Routing Benchmark has been updated with latest version of various web frameworks. http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html Note, wheezy.web seo routing benchmark has been improved by approximately 40%. Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: python-list@python.org Subject: Python Web Routing Benchmark Date: Wed, 10 Oct 2012 17:05:08 +0300 How fast web frameworks process routing (URL dispatch)? Here is a benchmark for various web frameworks (bottle, django, flask, pyramid, tornado and wheezy.web) running the following routing: static, dynamic, SEO and missing... with a trivial 'hello world' application (all routes are pointing to the same handler). http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html Benchmark is executed in isolated environment using CPython 2.7. Source is here: https://bitbucket.org/akorn/helloworld/src/tip/02-routing Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Web Frameworks Excessive Complexity
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
RE: Web Frameworks Excessive Complexity
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, 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: Lazy Attribute
from wheezy.core.descriptors import attribute as lazy @lazy def display_name... Thanks. Andriy Kornatskyy Date: Fri, 16 Nov 2012 09:56:41 +0200 From: s...@mweb.co.za To: python-list@python.org Subject: Re: Lazy Attribute On 2012/11/16 09:49 AM, Andriy Kornatskyy wrote: The name attribute is not very descriptive. Why not lazy_attribute instead? It just shorter and still descriptive. Shorter, but not descriptive. -- Regards Alex -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Lazy Attribute
Same applies to properties... they are seen as an object attributes. Thanks. Andriy From: steve+comp.lang.pyt...@pearwood.info Subject: Re: Lazy Attribute Date: Fri, 16 Nov 2012 09:04:39 + To: python-list@python.org On Fri, 16 Nov 2012 10:49:07 +0300, Andriy Kornatskyy wrote: Ian, Thank you for the comments. The name attribute is not very descriptive. Why not lazy_attribute instead? It just shorter and still descriptive. It is not descriptive. EVERYTHING accessed used dot notation obj.thing is an attribute. What makes your attribute different from ordinary attributes, properties, dynamic attributes calculated with __getattr__, methods, etc? -- Steven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Lazy Attribute
This is very minor use case. Unlikely useful to add any checks for None, or translate one exception to the other... with pretty much the same outcome: it makes sense in objects only. Thanks. Andriy From: rousl...@msn.com Subject: Re: Lazy Attribute Date: Fri, 16 Nov 2012 05:12:11 -0500 To: python-list@python.org On 11/16/2012 04:32 AM, Rouslan Korneychuk wrote: On 11/16/2012 02:49 AM, Andriy Kornatskyy wrote: If accessing the descriptor on the class object has no special meaning, then the custom is to return the descriptor object itself, as properties do. If I would satisfy this, I will be forced to check for None 99.9% of the use cases (it is not None, being applied to an object). Thus it behaves as designed. That's not true. You can use a try-except block to return the descriptor object when an AttributeError is raised. Actually, never mind. I just realized the function has to be called before the attribute can be set, which can not-only raise any exception, but could potentially have undesired side-effects given a parameter it doesn't expect. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Lazy Attribute
I believe it is not valid relate a lazy attribute as something `cached` since it cause confusion (e.g. delete of attribute cause cached item to be re-evaluated...), `cached` and `lazy` have completely different semantic meaning... however might overlap, as we see. Andriy From: steve+comp.lang.pyt...@pearwood.info Subject: Re: Lazy Attribute Date: Fri, 16 Nov 2012 10:29:03 + To: python-list@python.org On Thu, 15 Nov 2012 15:46:19 -0700, Ian Kelly wrote: Although you don't go into it in the blog entry, what I like about your approach of replacing the descriptor with an attribute is that, in addition to being faster, it makes it easy to force the object to lazily reevaluate the attribute, just by deleting it. You just lost me right there. That's a poor UI design -- it violates the principle of least surprise. If I delete something, it should be deleted. Consider your example: del p.display_name p.display_name 'Eliza Smith' That's very surprising. I am not aware of any other name in Python where deleting it does not remove the name from the namespace. (It is possible with properties, but I haven't ever come across someone who does that.) I don't have a good solution for invaliding such lazy attributes. Ideally we could have a new statement: refresh obj.attr # or some other name like invalidate but that won't happen. Other alternatives like: obj.attr.refresh() refresh(obj.attr) can't work because the function will see the result of the attribute lookup, not the lazy attribute itself. This won't do: obj.__class__.attr.refresh() because it won't know which instance to invalidate, although this could work: obj.__class__.attr.refresh(obj) # but it's ugly I'm very vaguely leaning towards this as the least-worst solution to invalidating the cached value: refresh(obj, 'attr') # pass the instance and the name -- Steven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Lazy Attribute
A lazy attribute is an attribute that is calculated on demand and only once. The post below shows how you can use lazy attribute in your Python class: http://mindref.blogspot.com/2012/11/python-lazy-attribute.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list
RE: Lazy Attribute
Ian, Thank you for the comments. The name attribute is not very descriptive. Why not lazy_attribute instead? It just shorter and still descriptive. If accessing the descriptor on the class object has no special meaning, then the custom is to return the descriptor object itself, as properties do. The lazy attribute, as a pattern, is designed to calculate something on demand, that being said means some `dynamic` nature must present, thus a class instance - object is a good candidate, while class itself is considered relatively `immutable`... of cause there might be extreme cases. If accessing the descriptor on the class object has no special meaning, then the custom is to return the descriptor object itself, as properties do. If I would satisfy this, I will be forced to check for None 99.9% of the use cases (it is not None, being applied to an object). Thus it behaves as designed. Thanks. Andriy Kornatskyy From: ian.g.ke...@gmail.com Date: Thu, 15 Nov 2012 15:24:40 -0700 Subject: Re: Lazy Attribute To: python-list@python.org On Thu, Nov 15, 2012 at 12:33 PM, Andriy Kornatskyy andriy.kornats...@live.com wrote: A lazy attribute is an attribute that is calculated on demand and only once. The post below shows how you can use lazy attribute in your Python class: http://mindref.blogspot.com/2012/11/python-lazy-attribute.html Comments or suggestions are welcome. The name attribute is not very descriptive. Why not lazy_attribute instead? I note that trying to access the descriptor on the class object results in an error: from descriptors import attribute class Foo: ... @attribute ... def forty_two(self): ... return 6 * 9 ... Foo().forty_two 54 Foo.forty_two Traceback (most recent call last): File stdin, line 1, in module File .\descriptors.py, line 33, in __get__ setattr(obj, f.__name__, val) AttributeError: 'NoneType' object has no attribute 'forty_two' If accessing the descriptor on the class object has no special meaning, then the custom is to return the descriptor object itself, as properties do. class Foo: ... @property ... def forty_two(self): ... return 6 * 9 ... Foo().forty_two 54 Foo.forty_two property object at 0x0280AD80 -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Lazy Attribute
Ian,
Thank you for mentioning about this research, really appreciate that.
Thanks.
Andriy Kornatskyy
From: ian.g.ke...@gmail.com
Date: Thu, 15 Nov 2012 15:46:19 -0700
Subject: Re: Lazy Attribute
To: python-list@python.org
On Thu, Nov 15, 2012 at 12:33 PM, Andriy Kornatskyy
andriy.kornats...@live.com wrote:
A lazy attribute is an attribute that is calculated on demand and only once.
The post below shows how you can use lazy attribute in your Python class:
http://mindref.blogspot.com/2012/11/python-lazy-attribute.html
Comments or suggestions are welcome.
I should add that I like the approach you're taking here. Usually
when I want a lazy property I just make an ordinary property of a
memoized function call:
def memoize(func):
cache = {}
@functools.wraps(func)
def wrapper(*args, **kwargs):
kwset = frozenset(kwargs.items())
try:
return cache[args, kwset]
except KeyError:
result = cache[args, kwset] = func(*args, **kwargs)
return result
return wrapper
class Foo:
def __init__(self):
self.times_called = 0
@property
@memoize # Alternatively, use functools.lru_cache
def forty_two(self):
self.times_called += 1
return 6 * 9
foo = Foo()
foo.times_called
0
foo.forty_two
54
foo.times_called
1
foo.forty_two
54
foo.times_called
1
Although you don't go into it in the blog entry, what I like about
your approach of replacing the descriptor with an attribute is that,
in addition to being faster, it makes it easy to force the object to
lazily reevaluate the attribute, just by deleting it. Using the
Person example from your blog post:
p = Person('John', 'Smith')
p.display_name
'John Smith'
p.display_name
'John Smith'
p.calls_count
1
p.first_name = 'Eliza'
del p.display_name
p.display_name
'Eliza Smith'
p.calls_count
2
Although in general it's probably better to use some form of reactive
programming for that.
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
RE: duck typing assert
Thank you for all comments. It makes very good sense to say: duckmatch(IFoo).compare(Foo) Since we do duck match of IFoo... but there is no `duck match`, there is `duck test`. I believe instead of `compare` is more readable with `equals`. Than it is more from mathematics - precise answer... that you can not guarantee at all in dynamic programming language. So it false to use such wording to reflect this check. We can only make an assumption that one looks like the other (similar)... with some limitation of cause... understanding what is `duck test`. http://en.wikipedia.org/wiki/Duck_test The intent is to make such language `construct` so it reads as English sentence that make sense, and not mandatory `pythonic` way (readability counts, java smokes aside). is_similar(Foo).to(IFoo) # = but we lost `duck test` sense here? Words `looks` and `like` are coming from duck test and point also direction: # 1 looks(Foo).like(IFoo, notice=['__len__'], ignore_funcs=['foo'], ignore_argspec['bar']) English sentence equivalent: if functions in Foo looks like one in IFoo than, probably, IFoo can be replaced with Foo; notice to check __len__, it is safe to ignore function `foo` and arguments passed to `bar`. # 2 looks(Foo, notice=['__len__'], ignore_funcs=['foo'], ignore_argspec['bar']).like(IFoo) English sentence equivalent: while looking at Foo notice to check `__len__`, it is safe to ignore function `foo` and arguments passed to `bar`, than probably it like IFoo. I think #1 is easier to understand once it is written. Thoughts? Also construction looks(Foo).like(IFoo) points direction of check. It you need the two be replaceable you need two asserts: assert looks(Foo).like(IFoo) assert looks(IFoo).like(Foo) Thanks. Andriy Kornatskyy Date: Fri, 9 Nov 2012 17:14:49 +1100 Subject: Re: duck typing assert From: ros...@gmail.com To: python-list@python.org On Fri, Nov 9, 2012 at 12:00 PM, Ian Kelly ian.g.ke...@gmail.com wrote: looks(Foo).like(IFoo), on the other hand, is crystal clear about which argument is which. I'm not so sure that it is, tbh. If you read it like an English sentence, it's clearly testing whether Foo matches the template in IFoo, but which are you more likely to do: test one class to see if it satisfies lots of templates, or test one template against every class you meet? I think probably the latter is, if not more likely than the former, at least sufficiently plausible as to create confusion. It makes very good sense to say: duckmatch(IFoo).compare(Foo) ie with the arguments the other way. ChrisA -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: duck typing assert
1. In looks-like we check features of Foo (that may be superset) of what IFoo offers. assert looks(Foo).like(IFoo) 2. We can check if Foo is limited to IFoo only: assert looks(IFoo).like(Foo) So it valid to have both asserts. Thanks. Andriy Kornatskyy From: steve+comp.lang.pyt...@pearwood.info Subject: Re: duck typing assert Date: Fri, 9 Nov 2012 13:36:39 + To: python-list@python.org On Thu, 08 Nov 2012 18:00:58 -0700, Ian Kelly wrote: On Thu, Nov 8, 2012 at 4:33 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 08 Nov 2012 20:34:58 +0300, Andriy Kornatskyy wrote: People who come from strongly typed languages that offer interfaces often are confused by lack of one in Python. Python, being dynamic typing programming language, follows duck typing principal. It can as simple as this: assert looks(Foo).like(IFoo) How very cute. And I don't mean that in a good way. Why is this a class with a method, instead of a function that takes two class arguments (plus any optional arguments needed)? looks_like(Foo, IFoo) is less cute, reads better to English speakers, and much more Pythonic. This isn't Java, not everything needs to be a class. I disagree. Does that test whether Foo looks like IFoo, or IFoo looks like Foo? What's the difference? Looks like is a symmetric comparison, like equal and almost equal, but not subset, less than etc. If x looks like y, then necessarily y must look like x. If Katy Perry looks like Zooey Deschanel, then it stands to reason that Zooey Deschanel looks like Katy Perry. James Woods looks like Erwin Schroedinger, and Erwin Schroedinger looks like James Woods. http://tvrefill.com/wp-content/uploads/2010/12/zooey-deschanel.jpg http://cheezburger.com/6704400128 So in that sense, looks(Spam).like(Ham) must always be the same as looks(Ham).like(Spam), and the order of operators doesn't matter. But that's not what we want! And to his credit, that's not what Andriy Kornatskyy's code actually implements. The problem is with the name, which is actively misleading by suggesting a symmetrical comparison for one which is not symmetrical. Suppose we want to make a movie with Zooey Deschanel, but she's not available, so we want a replacement who is duck-type compatible with her. The replacement doesn't need to be a Deschanel sister, but she does need to do *at least* everything Zooey can do. If she can do more, that's fine, but she can't do less. Since Katy Perry can do everything Zooey can do, PLUS she sings, we can replace Zooey with Katy: Katy is duck-type compatible with Zooey. But we can't replace Katy with Zooey, because Zooey can't sing.[1] (I think... I really don't actually know if Zooey Deschanel can sing or not. Just go along with the example.) The point I am making is that looks like is not a good description for this function. Looks like must be symmetrical, but the function we actually want is not symmetrical. It is actually a subset type relationship: given looks(Zooey).like(Katy), it checks that the public methods etc. of Zooey are a subset of the methods of Katy. That is, that instances of Katy can be used instead of instances of Zooey. Or is it the other way? Damned if I know. Let's find out: class Zooey: def act(self): pass class Katy: def act(self): pass def sing(self): pass py looks(Zooey).like(Katy) __main__:2: UserWarning: 'sing': is missing. False I guessed wrong. The looks.like method as implemented tests that the right-hand size operand is a subset of the right-hand-side: py looks(Katy).like(Zooey) True I argue that this is the wrong way around. (Even if it isn't the wrong way around, it certainly isn't clear or obvious which way you have to write the operands!) Consider this use-case: candidates = [Hilary, Jennifer, Katy] expected = looks(Zooey) # instantiate the looks class once only for actor in candidates: if expected.like(actor): make_movie_with(actor()) That's much nicer and more efficient than the way you have to write it now: candidates = [Hilary, Jennifer, Katy] for actor in candidates: # instantiate the looks class every time we want to test another class if looks(actor).like(Zooey): make_movie_with(actor()) So... it's a cute name, that sounds English-like. But it doesn't actually describe what the function does, it is wasteful for at least one useful use-case, and it's not clear which order you have to supply the two arguments. looks(Foo).like(IFoo), on the other hand, is crystal clear about which argument is which. I hope that by now you can see why I say that it is as clear as mud. [1] Some people might argue that neither can Katy Perry. -- Steven -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: duck typing assert
There is sense for #2. Let me explain. There is basic IFoo implementation and improved Foo. While I switched to Foo, I still want to be as close to IFoo as possible, since there might be sense to switch to Foo2 later, which conform to IFoo. Here is the problem: if I will not assert #2 potentially I will use some `features` that are not in IFoo, thus that breaks my code switching to Foo2 later. That might not apply for 100% usability cases, just wanted to point that out as reasonable thing. Thanks. Andriy Kornatskyy Date: Sat, 10 Nov 2012 01:15:36 +1100 Subject: Re: duck typing assert From: ros...@gmail.com To: python-list@python.org On Sat, Nov 10, 2012 at 1:01 AM, Andriy Kornatskyy andriy.kornats...@live.com wrote: 1. In looks-like we check features of Foo (that may be superset) of what IFoo offers. assert looks(Foo).like(IFoo) 2. We can check if Foo is limited to IFoo only: assert looks(IFoo).like(Foo) So it valid to have both asserts. You'll almost never need #2, but since there's no difference between a class and an interface, it's perfectly legal to switch them around. But I would generally expect that unrecognized methods are never a problem (assuming they don't collide with anything) - that, as in Steven's example, it's fine to have an actor who can sing when you don't need her to. When you post job openings, you don't normally ask for someone with 5+ years Python experience and unable to program in REXX [1]. You're checking for a minimum set of requirements. [1] Though I suppose you might ask for someone who's unable to program in Pascal. Might save you some hassle. ChrisA -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: duck typing assert
duck(Foo).match(IFoo, kwargs) duck(Foo).like(IFoo, kwargs) Hm... function name in most cases is read as verb... this may cause confusion: duck = synonyms = immerse, dip Thanks. Andriy Kornatskyy From: ramit.pra...@jpmorgan.com To: andriy.kornats...@live.com; python-list@python.org Subject: RE: duck typing assert Date: Fri, 9 Nov 2012 17:37:29 + Andriy Kornatskyy wrote: Thank you for all comments. It makes very good sense to say: duckmatch(IFoo).compare(Foo) Since we do duck match of IFoo... but there is no `duck match`, there is `duck test`. I believe instead of `compare` is more readable with `equals`. Than it is more from mathematics - precise answer... that you can not guarantee at all in dynamic programming language. So it false to use such wording to reflect this check. We can only make an assumption that one looks like the other (similar)... with some limitation of cause... understanding what is `duck test`. http://en.wikipedia.org/wiki/Duck_test The intent is to make such language `construct` so it reads as English sentence that make sense, and not mandatory `pythonic` way (readability counts, java smokes aside). is_similar(Foo).to(IFoo) # = but we lost `duck test` sense here? Words `looks` and `like` are coming from duck test and point also direction: # 1 looks(Foo).like(IFoo, notice=['__len__'], ignore_funcs=['foo'], ignore_argspec['bar']) English sentence equivalent: if functions in Foo looks like one in IFoo than, probably, IFoo can be replaced with Foo; notice to check __len__, it is safe to ignore function `foo` and arguments passed to `bar`. # 2 looks(Foo, notice=['__len__'], ignore_funcs=['foo'], ignore_argspec['bar']).like(IFoo) English sentence equivalent: while looking at Foo notice to check `__len__`, it is safe to ignore function `foo` and arguments passed to `bar`, than probably it like IFoo. What about? duck(Foo).equivalent_to(IFoo, kwargs) duck(Foo).matches(IFoo, kwargs) This email is confidential and subject to important disclaimers and conditions including on offers for the purchase or sale of securities, accuracy and completeness of information, viruses, confidentiality, legal privilege, and legal entity disclaimers, available at http://www.jpmorgan.com/pages/disclosures/email. -- http://mail.python.org/mailman/listinfo/python-list
duck typing assert
People who come from strongly typed languages that offer interfaces often are confused by lack of one in Python. Python, being dynamic typing programming language, follows duck typing principal. It can as simple as this: assert looks(Foo).like(IFoo) The post below shows how programmer can assert duck typing between two Python classes: mindref.blogspot.com/2012/11/python-duck-typing-assert.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list
duck typing assert
People who come from strongly typed languages that offer interfaces often are confused by lack of one in Python. Python, being dynamic typing programming language, follows duck typing principal. It can as simple as this: assert looks(Foo).like(IFoo) The post below shows how programmer can assert duck typing between two Python classes: http://mindref.blogspot.com/2012/11/python-duck-typing-assert.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list
RE: duck typing assert
Ian, Thank you for the comments. There is definitely a room for improvement, however there are limits. One of them is related to decorator that replaces decorated method arguments with something like *args, **kwargs. Here is an example. def x(): def decorate(m): def x(*args, **kwargs): pass return x return decorate class Foo(object): @x def bar(self, a): pass Another one challenge is related to inheritance, or even more complex case: multiple inheritance. I do not believe there is a need to scan whole hierarchy, better apply checks separately, the assert will be more readable. class IFoo(object): def foo(self): pass class IBar(IFoo): def bar(self): pass class Bar(IBar): def foo(self): pass def bar(self): pass assert looks(Bar).like(IBar) assert looks(Bar).like(IFoo) I agree, special methods __?__ should not be considered private... but what is right: know which one are special (how about some custom? e.g. __ctx__) or enforce check for it by explicitly asking for such check? # 1 assert looks(Foo).like(IFoo, notice=['__len__']) # 2 assert looks(Foo, notice=['__len__']).like(IFoo) I believe if IFoo.foo is decorated as property, it must remain property, otherwise you need exclude it from checks, thus this way you pay code reviewer attention to that. Thanks. Andriy Kornatskyy From: ian.g.ke...@gmail.com Date: Thu, 8 Nov 2012 11:34:45 -0700 Subject: Re: duck typing assert To: python-list@python.org On Thu, Nov 8, 2012 at 10:30 AM, Andriy Kornatskyy andriy.kornats...@live.com wrote: People who come from strongly typed languages that offer interfaces often are confused by lack of one in Python. Python, being dynamic typing programming language, follows duck typing principal. It can as simple as this: assert looks(Foo).like(IFoo) The post below shows how programmer can assert duck typing between two Python classes: mindref.blogspot.com/2012/11/python-duck-typing-assert.html Comments or suggestions are welcome. Overall, it looks potentially useful to me. Looking over the wheezy.core.introspection source, it appears to ignore special method names. For example, if you do: class IFoo(object): def __len__(self): pass class Foo(object): pass assert looks(Foo).like(IFoo) I would expect this to fail, but judging from the code it would not, as it ignores all names starting with '_'. That makes some sense for private names (but on the other hand, why would you declare private names in an interface unless you want to enforce their presence?), but names like __len__ should not be considered private. Another comment I have is on properties, and descriptors in general. Does this allow something declared as a property to be implemented as a simple class attribute, and vice versa? Or can something declared as a property be implemented with some custom descriptor class? I think the answer is no to both, as the check it performs is t2.__class__ is not t.__class__. I assert though that in general the type of a descriptor (that is not a simple class attribute) is not as important in duck testing as its API -- and all descriptors have basically the same API of __get__, __set__, and __delete__. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: How to generate account number?
Jose, absolutely, let me know should you have any issues. Andriy Date: Fri, 2 Nov 2012 15:29:13 -0600 Subject: Re: How to generate account number? From: josen.figue...@unixmexico.org To: andriy.kornats...@live.com CC: python-list@python.org Hello Andriy Thanks for your work! I will try it! Jose On Fri, Nov 2, 2012 at 3:13 PM, Andriy Kornatskyy andriy.kornats...@live.commailto:andriy.kornats...@live.com wrote: Requirements for `account number` generator: 1. Issue pseudo random consistent number (must be unique for dozen millions of records) 2. Easy check validity (without a need to make a database call) Interested? Read more here: http://mindref.blogspot.com/2012/11/generate-account-number.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: How to generate account number?
from hashlib import sha1
sha1('GangGreene-20120203-1012').hexdigest()
'ef764a2fe44532008dc9a99c391c70cd85ec9d82'
It is too long and not verifiable.
from uuid import uuid4
uuid4()
UUID('2c14484b-5a0c-4f4b-b7bc-8187548b4888')
Pretty much the same what you suggest but simpler and shorter. Not quite
elegant for humans.
Here are examples per this post:
http://mindref.blogspot.com/2012/11/generate-account-number.html
account_number(1)
'Z05738521581'
account_number(2)
'Z17888279480'
account_number(3)
'Z07395350007'
Short, human readable and satisfy original requirements.
Andriy
From: ganggre...@example.com
Subject: Re: How to generate account number?
Date: Fri, 2 Nov 2012 18:02:09 -0400
To: python-list@python.org
On Sat, 03 Nov 2012 00:13:19 +0300, Andriy Kornatskyy wrote:
Requirements for `account number` generator:
1. Issue pseudo random consistent number (must be unique for dozen
millions of records)
2. Easy check validity (without a need to make a database call)
Interested? Read more here:
http://mindref.blogspot.com/2012/11/generate-account-number.html
Comments or suggestions are welcome.
Thanks.
Andriy Kornatskyy
generate sha1sum on the ((key database record(s))+date+timeofday)
Should be unique for billions/trillions of records.
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
RE: How to generate account number?
Steven, see below, please. From: steve+comp.lang.pyt...@pearwood.info Subject: Re: How to generate account number? Date: Fri, 2 Nov 2012 22:39:31 + To: python-list@python.org On Sat, 03 Nov 2012 00:13:19 +0300, Andriy Kornatskyy wrote: Requirements for `account number` generator: 1. Issue pseudo random consistent number (must be unique for dozen millions of records) How much randomness do you need? From the perspective of any one user, a simple incrementing counter returns arbitrary values, which may be close enough to random. last_num = 103872 # Pick an arbitrary starting value. def get_account_number(): Return the next account number. global last_num last_num += 1 return last_num Stick that value in a database instead of a global, and you're done. What are the consequences of people guessing account numbers? If the consequences are serious, then you need to make account numbers cryptographically strong. If the account number alone is not important, then you don't. Yes. There are consequences to not use sequential numbers, yet humans deal with it (enter as input somewhere, etc). The approach suggested here: http://mindref.blogspot.com/2012/11/generate-account-number.html is using Feistel cipher to generate pseudo random thus makes guessing account numbers hard (impossible?). 2. Easy check validity (without a need to make a database call) Add a check digit to the number you generate. There are all sorts of ways to do that. Here are two examples: http://code.activestate.com/recipes/577692 http://code.activestate.com/recipes/577691 These tell me how to verify some code, but doesn't how to generate it. The approach suggested here: http://mindref.blogspot.com/2012/11/generate-account-number.html gives you ability to customize `sample_f` function to make it unique to your business case. Interested? Read more here: If you ask a question here, please keep the discussion here, don't split it to your personal blog. The question was rhetorical with my answer in the blog and discussion here to reach something. Tell us your requirements in more detail, and we will try to help you. I have presented solution to `account number` challenge. So it was share with community and seek for thoughts if any. -- http://mail.python.org/mailman/listinfo/python-list
RE: How to generate account number?
Roy, Per your advise: from base64 import b32encode human_format = lambda n: 'Z%s-%s' % (b32encode(chr((n 24) 255) + chr((n 16) 255))[:4], b32encode(chr((n 8) 255) + chr(n 255))[:4]) human_format(5738521581) 'ZKYFA-4PWQ' human_format(17888279480) 'ZFI4Q-PO4A' human_format(7395350007) 'ZXDGA-CX3Q' Side by side: Z05738521581 = ZKYFA-4PWQ Z17888279480 = ZFI4Q-PO4A Z07395350007 = ZXDGA-CX3Q Thanks. Andriy From: r...@panix.com Subject: Re: How to generate account number? Date: Sat, 3 Nov 2012 09:22:55 -0400 To: python-list@python.org In article mailman.3234.1351931985.27098.python-l...@python.org, Andriy Kornatskyy andriy.kornats...@live.com wrote: 'Z05738521581' 'Z17888279480' 'Z07395350007' Short, human readable and satisfy original requirements. Andriy If you really want human readable, it's better to chunk the data up into 3 or 4 digit groups. So, instead of Z05738521581, maybe Z05-738-521-581. Or perhaps even better, Z05-7385-21-581 (just a hunch, but I suspect varying the length of the groups makes it easier to read). Even better might be base-32 encoding the value. Strings of digits have an information density of about 3.2 bits/char. Base-32 is just about as readable, but gives you 5 bits/char, so you end up with a few less characters (which you still want to chunk into 3 or 4 character groups). -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: How to generate account number?
Tim,
Good point. b32decode seems to be capable to understand such common mistakes
(see map01 argument to b32decode), I haven't tried:
http://docs.python.org/2/library/base64.html
Thanks.
Andriy
Date: Sat, 3 Nov 2012 10:34:26 -0500
From: python.l...@tim.thechases.com
To: r...@panix.com
Subject: Re: How to generate account number?
CC: python-list@python.org
On 11/03/12 08:22, Roy Smith wrote:
Even better might be base-32 encoding the value. Strings of
digits have an information density of about 3.2 bits/char.
Base-32 is just about as readable, but gives you 5 bits/char, so
you end up with a few less characters (which you still want to
chunk into 3 or 4 character groups).
For things that will be read off a screen/paper, I recommend
omitting several letters that are easy to mistake visually: i/I/l/1
and O/0 in particular. The VIN (vehicle identification number) on
all US cars avoids these characters[*], making it easier to read
them back without concern for is that a zero or an oh; and is that
an ell, a one, a lowercase eye, or a capital eye? As an encoding
advantage,
print len(''.join(c for c in (string.ascii_uppercase +
string.digits) if c not in O0iIl1))
32
the number 32 is pretty handy when dealing with binary :-)
-tkc
[*]
The VIN avoids Q too and does use the digits 0/1, but the idea
holds. Make it easy to ready back.
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Per community request turbogears and pysi were added. The following posts have been updated: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html http://mindref.blogspot.com/2012/10/python-web-pep8-consistency.html Comments or suggestions are welcome. Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest web framework Date: Sun, 23 Sep 2012 12:19:16 +0300 I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Alex, You can read wheezy.web introduction here: http://mindref.blogspot.com/2012/10/wheezy-web-introduction.html Thanks. Andriy Kornatskyy Date: Mon, 15 Oct 2012 18:26:16 -0700 Subject: Re: Fastest web framework From: wuwe...@gmail.com To: python-list@python.org On Oct 15, 11:40 pm, Andriy Kornatskyy andriy.kornats...@live.com wrote: Comments or suggestions are welcome. Performance speed is possibly the least interesting aspect of web frameworks; ease of use readily re-usable 3rd party code figures much higher, IMO. Rather than constantly hammer on about performance, maybe you could take the time to explain any other advantages your framework provides. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Web content caching is the most effective type of cache. This way your python handler is not executed to determine a valid response to user, instead one returned from cache. Since the operation is that simple, it should be the maximum possible speed your `real world` application capable to provide. The web content caching benchmark is provided for two types of caching: memory and distributed. There is payed attention how gzip transform impact throughput of cached content. Read more here: http://mindref.blogspot.com/2012/10/python-web-caching-benchmark.html Your ability to utilize managed (semi-real time) caching is essential to be able run your `real world` at the speed of `hello world`. Read more here: http://packages.python.org/wheezy.http/userguide.html#content-cache http://packages.python.org/wheezy.web/tutorial.html Compare throughput with numbers from the other post: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest web framework Date: Sun, 23 Sep 2012 12:19:16 +0300 I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest template engine
Python template engines offer high reusability of markup code and the following features are used by content developers most of the time: * Includes: useful to incorporate some snippets of content that in most cases are common to the site, e.g. footer, scripts, styles, etc. * Extends: useful to define a master layout for the majority of the site content with placeholders, e.g. sidebar, horizontal menu, content, etc. The content developers extend the master layout by substituting available placeholders. * Widgets: usually small snippets of highly reusable markup, e.g. list item, button, etc. The content developers use widgets to increase readability and enforce consistency of design. All mentioned features above are examined for various template engines (django, jinja2, mako, tornado and wheezy.template) in the following post: http://mindref.blogspot.com/2012/10/python-templates-benchmark.html The test is executed in isolated environment using CPython 2.7 but can be run for Python 3.3 and/or PyPy 1.9. Source code is here: https://bitbucket.org/akorn/helloworld Comments or suggestions are welcome. Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: RE: Fastest template engine Date: Fri, 19 Oct 2012 11:34:41 +0300 Per community request cheetah has been added to benchmark. Post updated, just in case: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: RE: Fastest template engine Date: Wed, 26 Sep 2012 16:21:21 +0300 The post has been updated with the following template engines added (per community request): 1. chameleon 2. django 3. web2py Here is a link: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest template engine Date: Sun, 23 Sep 2012 12:24:36 +0300 I have run recently a benchmark of a trivial 'big table' example for various python template engines (jinja2, mako, tenjin, tornado and wheezy.template) run on cpython2.7 and pypy1.9.. you might find it interesting: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest template engine
Per community request cheetah has been added to benchmark. Post updated, just in case: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: RE: Fastest template engine Date: Wed, 26 Sep 2012 16:21:21 +0300 The post has been updated with the following template engines added (per community request): 1. chameleon 2. django 3. web2py Here is a link: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest template engine Date: Sun, 23 Sep 2012 12:24:36 +0300 I have run recently a benchmark of a trivial 'big table' example for various python template engines (jinja2, mako, tenjin, tornado and wheezy.template) run on cpython2.7 and pypy1.9.. you might find it interesting: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Python Web Frameworks PEP8 Consistency
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: Fastest web framework
Per community request I have updated benchmarks for web2py 2.1.1 release (the newer version performs 26% better; no error while running on pypy): Here are updated posts, just in case: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: RE: Fastest web framework Date: Tue, 9 Oct 2012 16:44:19 +0300 How fast python web framework process routing (URL dispatch)? Here is a benchmark for various web frameworks (bottle, django, flask, pyramid, tornado and wheezy.web) running the following routing: static, dynamic, SEO and missing... with a trivial 'hello world' application (all routes are pointing to the same handler). http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html Benchmark is executed in isolated environment using CPython 2.7. Comments or suggestions are welcome. Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest web framework Date: Sun, 23 Sep 2012 12:19:16 +0300 I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Alex, Thank you, see my answers inline to your comments: Performance speed is possibly the least interesting aspect of web frameworks; Performance and effectivity are related metrics. Longer feature list can not explain why it less effective. An answer to effectivity question might be related to: - code quality (we have PEP8) - architectural decisions taken - core team experience - historical path, etc. ease of use readily re-usable 3rd party code figures much higher, IMO. I think these are very valid requirements for the modern web framework. I believe all web frameworks are easy to use (... some too seriously take this?), of cause readability/flexibility counts. There is a problem with 3rd party code... it should evolve with framework... so good one become a part of it. 3rd party UI things are good, until you start `customize` them, patch, workaround, etc. This is where pain come from. However, there are exceptions. Can you name few? Rather than constantly hammer on about performance, maybe you could take the time to explain any other advantages your framework provides. Let me state this: wheezy.web let you design web application to be able run it at the speed of `hello world`, even database driven one. Here is how: use content caching with cache dependency. Read more: http://packages.python.org/wheezy.http/userguide.html#content-cache Invest 30 minutes to understand it: http://packages.python.org/wheezy.web/tutorial.html All web frameworks are good, some better. It is important what you see as an advantage... Thanks. Andriy Kornatskyy Date: Mon, 15 Oct 2012 18:26:16 -0700 Subject: Re: Fastest web framework From: wuwe...@gmail.com To: python-list@python.org On Oct 15, 11:40 pm, Andriy Kornatskyy andriy.kornats...@live.com wrote: Comments or suggestions are welcome. Performance speed is possibly the least interesting aspect of web frameworks; ease of use readily re-usable 3rd party code figures much higher, IMO. Rather than constantly hammer on about performance, maybe you could take the time to explain any other advantages your framework provides. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Demian, Thank you, I appreciate your input. See below. Performance and effectivity are related metrics. Longer feature list can not explain why it less effective. An answer to effectivity question might be related to: - code quality (we have PEP8) Any static code analysis such as pylint or pyflakes? Yep, good start with any of those. - architectural decisions taken What (sample of) decisions? How do they differ from other frameworks? How will they make my life better? The initial decisions taken while building a project might be wrong. Due to continues backward compatibility, you can not change them even you wish. Some projects die and same people start a new one, rethinking mistakes made. - core team experience Not sure this is entirely relevant (imho). Engineers with great experience on paper may still make poor decisions and output shoddy work. Conversely, a new grad (or weekend hacker) may have a solid understanding and output amazing work. The question is about the practical things you do daily. You might laugh of your first project, you continue to move forward and got respect as it is now. Imagine you continue to fix your first program up to now, you will probably write is somewhat differently. Same applies to frameworks, pursue effectiveness for more: users served, application hosted, etc. Some, just can not. - historical path, etc. What does this mean? The frameworks are not written in one day, they have historical path with many hands on it. This change it, not always right way. There is a problem with 3rd party code... it should evolve with framework... so good one become a part of it. 3rd party UI things are good, until you start `customize` them, patch, workaround, etc. This is where pain come from. However, there are exceptions. Can you name few? [Disclaimer: personal opinion] I couldn't disagree more. A good framework provides the glue for various subsystems to work amazingly well together. Perhaps this is why I'm drawn to micro-frameworks and the likes of Pyramid. No assumptions are made about *how* I'm going to use the framework. Modularity is good. Do one thing and do it *very* well. Caching? Use beaker. ORM? Use SQLAlchemy. That glue is usability case: recommendation how to use it with one or the other. Let me state this: wheezy.web let you design web application to be able run it at the speed of `hello world`, even database driven one. This bothers me. It's misleading to newbies and it's just wrong. You simply *cannot* have a database driven application run at the exact same performance as a hello world app. For you, personally, let me point this again. N.P. Here is how: use content caching with cache dependency. Read more: http://packages.python.org/wheezy.http/userguide.html#content-cache Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Demian, Thank you, see below. I think that my first batch of questions were slightly out of context, mostly due to a lack of caffeine first thing in the morning. My understanding at the time was that your an answer to effectivity was, in fact, a list of highlights for wheezy.web (which is why I asked the questions I did). Having said that.. The initial decisions taken while building a project might be wrong. Due to continues backward compatibility, you can not change them even you wish. You can always deprecate old functionality in favor of new solutions. I'd be hard pressed to find a reason to find a reason why something *can't* be deprecated. It may not be easy at times, but it should always be doable. And that is the problem. Some can not deprecate and die (see pylons, now pyramid). Some can not die nor deprecate (see django). That glue is usability case: recommendation how to use it with one or the other. As long as your framework doesn't require you to fight with it in order to use another solution. One of my early gripes with Django for example (ages ago) was that it felt like I had to fight the framework in order to introduce functionality that wasn't natively supported. For you, personally, let me point this again. N.P. Here is how: use content caching with cache dependency. Read more: http://packages.python.org/wheezy.http/userguide.html#content-cache It doesn't matter if you're using cached content or not. It will *not* be as fast as a hard-coded, simple response (not that a static, hard-coded response is the way to go obviously). I don't think I have to get into the details about I/O. My point is simply that the statement that a database driven site (cached content or not), *can not* be as fast as a hello world app. My comment may be construed as being nit-picky, but I thought it was worth calling out due to the matter-of-fact wording that you used. It does. There is certain level after which performance of `hello world` will not differ from real world application. The hardware I used got that limit at 22-24K per second. That is why I made isolated benchmarks. See difference between wsgi sample and others. http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html On a somewhat unrelated note, I caught a minor typo in the content-cache docs: Since there is no heavy processing and just simple operation to get an item from cache it should be supper fast I don't know about you, but my supper generally isn't fast ;) You will see. Thanks. supper = super ;-) Somewhat later in a week there will be another benchmark for... caching. Take care. Andriy -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
How fast python web frameworks reverse urls? While routing is a mapping of incoming request to a handler, url reverse function is designed to build urls for those handlers. A web page may have a number of urls from few dozen to hundreds... all related to your web site (e.g. links between related pages, tag cloud, most viewed posts, etc). Here is a benchmark for various web frameworks (django, flask, pyramid, tornado and wheezy.web): http://mindref.blogspot.com/2012/10/python-web-reverse-urls-benchmark.html Benchmark is executed in isolated environment using CPython 2.7. Source is here: https://bitbucket.org/akorn/helloworld/src/tip/03-urls Comments or suggestions are welcome. Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest web framework Date: Sun, 23 Sep 2012 12:19:16 +0300 I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Python Web Routing Benchmark
How fast web frameworks process routing (URL dispatch)? Here is a benchmark for various web frameworks (bottle, django, flask, pyramid, tornado and wheezy.web) running the following routing: static, dynamic, SEO and missing... with a trivial 'hello world' application (all routes are pointing to the same handler). http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html Benchmark is executed in isolated environment using CPython 2.7. Source is here: https://bitbucket.org/akorn/helloworld/src/tip/02-routing Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
How fast python web framework process routing (URL dispatch)? Here is a benchmark for various web frameworks (bottle, django, flask, pyramid, tornado and wheezy.web) running the following routing: static, dynamic, SEO and missing... with a trivial 'hello world' application (all routes are pointing to the same handler). http://mindref.blogspot.com/2012/10/python-web-routing-benchmark.html Benchmark is executed in isolated environment using CPython 2.7. Comments or suggestions are welcome. Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest web framework Date: Sun, 23 Sep 2012 12:19:16 +0300 I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
In order to provide more reliable benchmark, I get rid of application server and network boundary. As a result I simulated a valid WSGI request and isolated calls just to the web framework alone. Also I found interesting to take a look at total number of calls and unique functions used by corresponding web framework. The post has been updated: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Isolated benchmark source code is here: https://bitbucket.org/akorn/helloworld/src/tip/benchmark.py I should mention several web frameworks experience huge memory leaks in this benchmark. BONUS: added benchmark for python 3.3 (for the web frameworks that support it) and plain simple WSGI application (for contrast). Comments or suggestions are welcome. Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: ta...@ziade.org Subject: RE: Fastest web framework Date: Sat, 29 Sep 2012 12:18:32 +0300 CC: python-list@python.org Tarek, My response inline to your: You are not getting my point. What happens to weezhy or XXX framework when you are running it in a given stack, under heavy load ? let me correct you, it is wheezy.web (not `weezhy`). Tell me your definition of web framework heavy load. If you have one, we can try benchmark it. There are many interactions that may impact the behavior of the stack - most of them are in the web server itself, but they can be things in the framework too, depending on the architectural choice. The reason I choose uWSGI is due to minimal possible impact that application server may cause. Since this component `equally influence` productivity of each framework it can be to some degree ignored. And you will not know it with an hello world app. To put it more bluntly, your benchmark is going to join the big pile of hello worlds benchmarks that are completely meaningless. Can not agree. This is just simple thing. Simple things should run fast, no doubt. If you can provide a better idea as to which framework calls to put into benchmark, I will be happy extend the benchmark case. If you want to prove that weezhy is faster than another py framework, because, I dunno, the number of function calls are smaller ? then you need to isolate this and do a different kind of bench. Have a look at http://plope.com/pyroptimization , it's a good example The numbers provided in that article are incorrect. They didn't match results from the file they provide (result.txt in each framework dir) at the time of writing. I have used that idea to re-run things (isolated benchmark; report with total time, total number of calls and number of distinct functions used). See here: https://bitbucket.org/akorn/helloworld/src/tip/benchmark.py I will update original post a bit later (to let you comment on this). Same thing for the raw speed of your templating engine - isolation is required. Improved bigtable benchmark report by adding total number of calls and number distinct functions used: https://bitbucket.org/akorn/wheezy.template/src/tip/demos/bigtable/bigtable.py Original post not updated yet. One good read: http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/ Sounds not so bad. It points to some specific workloads. Any attempt to prioritize and/or practically implement them? Thanks. Andriy -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest template engine
1. Added benchmarks for python 3.3 2. Captured total numbers of calls made by corresponding template engine and number of unique functions used. http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest template engine Date: Sun, 23 Sep 2012 12:24:36 +0300 I have run recently a benchmark of a trivial 'big table' example for various python template engines (jinja2, mako, tenjin, tornado and wheezy.template) run on cpython2.7 and pypy1.9.. you might find it interesting: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Tarek, My response inline to your: You are not getting my point. What happens to weezhy or XXX framework when you are running it in a given stack, under heavy load ? let me correct you, it is wheezy.web (not `weezhy`). Tell me your definition of web framework heavy load. If you have one, we can try benchmark it. There are many interactions that may impact the behavior of the stack - most of them are in the web server itself, but they can be things in the framework too, depending on the architectural choice. The reason I choose uWSGI is due to minimal possible impact that application server may cause. Since this component `equally influence` productivity of each framework it can be to some degree ignored. And you will not know it with an hello world app. To put it more bluntly, your benchmark is going to join the big pile of hello worlds benchmarks that are completely meaningless. Can not agree. This is just simple thing. Simple things should run fast, no doubt. If you can provide a better idea as to which framework calls to put into benchmark, I will be happy extend the benchmark case. If you want to prove that weezhy is faster than another py framework, because, I dunno, the number of function calls are smaller ? then you need to isolate this and do a different kind of bench. Have a look at http://plope.com/pyroptimization , it's a good example The numbers provided in that article are incorrect. They didn't match results from the file they provide (result.txt in each framework dir) at the time of writing. I have used that idea to re-run things (isolated benchmark; report with total time, total number of calls and number of distinct functions used). See here: https://bitbucket.org/akorn/helloworld/src/tip/benchmark.py I will update original post a bit later (to let you comment on this). Same thing for the raw speed of your templating engine - isolation is required. Improved bigtable benchmark report by adding total number of calls and number distinct functions used: https://bitbucket.org/akorn/wheezy.template/src/tip/demos/bigtable/bigtable.py Original post not updated yet. One good read: http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/ Sounds not so bad. It points to some specific workloads. Any attempt to prioritize and/or practically implement them? Thanks. Andriy Date: Wed, 26 Sep 2012 11:41:26 +0200 From: ta...@ziade.org To: andriy.kornats...@live.com CC: python-list@python.org Subject: Re: Fastest web framework On 9/26/12 11:26 AM, Andriy Kornatskyy wrote: Tarek, Thank you for the response back. Yes, your idea is pretty clear to me. The point is that higher workload you put in your application business logic, repository, backend, whatever... less you will see in final results comparison. This is obvious and we, as technical people, very well understand this (somebody even laugh). I am happy somebody got a good laugh, I had a myself a good coffee :) The reality is that not all web applications do heavy CPU computations and/or experience IO delays (due to response from database running a query over table that has no index, let say), some use caches, some split jobs to be run in background, some parallel them... I have to state that simple things must perform really fast to give more room for one that are not so. That in turn makes your infrastructure more effective. Some prefer to add a box, some see that a likely to be a problem further it goes. The good thing - you have a choice, you are not locked, and as result you are responsible for the effectiveness of the system you build today and definitely next one. Take care. Andriy You are not getting my point. What happens to weezhy or XXX framework when you are running it in a given stack, under heavy load ? There are many interactions that may impact the behavior of the stack - most of them are in the web server itself, but they can be things in the framework too, depending on the architectural choice. And you will not know it with an hello world app. To put it more bluntly, your benchmark is going to join the big pile of hello worlds benchmarks that are completely meaningless. If you want to prove that weezhy is faster than another py framework, because, I dunno, the number of function calls are smaller ? then you need to isolate this and do a different kind of bench. Have a look at http://plope.com/pyroptimization , it's a good example Same thing for the raw speed of your templating engine - isolation is required. One good read: http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need/ Cheers Tarek Date: Wed, 26 Sep 2012 11:08:19 +0200 From: ta...@ziade.org To: andriy.kornats...@live.com CC: python-list@python.org Subject: Re: Fastest web framework On 9/25/12 3:21 PM, Andriy
RE: [RELEASED] Python 3.3.0
The following doctest fails with python3.3 (it is okay for python2.4-2.7, 3.2).
class adict(dict):
d = adict(a=1, b=2)
d
{'a': 1, 'b': 2}
if __name__ == __main__:
import doctest
doctest.testmod()
Please advise if that is something known.
Andriy
Date: Sat, 29 Sep 2012 14:18:54 +0200
From: ge...@python.org
To: python-annou...@python.org; python-...@python.org; python-list@python.org
Subject: [RELEASED] Python 3.3.0
On behalf of the Python development team, I'm delighted to announce the
Python 3.3.0 final release.
Python 3.3 includes a range of improvements of the 3.x series, as well
as easier porting between 2.x and 3.x. Major new features and changes
in the 3.3 release series are:
* PEP 380, syntax for delegating to a subgenerator (yield from)
* PEP 393, flexible string representation (doing away with the
distinction between wide and narrow Unicode builds)
* A C implementation of the decimal module, with up to 120x speedup
for decimal-heavy applications
* The import system (__import__) now based on importlib by default
* The new lzma module with LZMA/XZ support
* PEP 397, a Python launcher for Windows
* PEP 405, virtual environment support in core
* PEP 420, namespace package support
* PEP 3151, reworking the OS and IO exception hierarchy
* PEP 3155, qualified name for classes and functions
* PEP 409, suppressing exception context
* PEP 414, explicit Unicode literals to help with porting
* PEP 418, extended platform-independent clocks in the time module
* PEP 412, a new key-sharing dictionary implementation that
significantly saves memory for object-oriented code
* PEP 362, the function-signature object
* The new faulthandler module that helps diagnosing crashes
* The new unittest.mock module
* The new ipaddress module
* The sys.implementation attribute
* A policy framework for the email package, with a provisional (see
PEP 411) policy that adds much improved unicode support for email
header parsing
* A collections.ChainMap class for linking mappings to a single unit
* Wrappers for many more POSIX functions in the os and signal
modules, as well as other useful functions such as sendfile()
* Hash randomization, introduced in earlier bugfix releases, is now
switched on by default
In total, almost 500 API items are new or improved in Python 3.3.
For a more extensive list of changes in 3.3.0, see
http://docs.python.org/3.3/whatsnew/3.3.html
To download Python 3.3.0 visit:
http://www.python.org/download/releases/3.3.0/
This is a production release, please report any bugs to
http://bugs.python.org/
Enjoy!
--
Georg Brandl, Release Manager
georg at python.org
(on behalf of the entire python-dev team and 3.3's contributors)
--
http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
CherryPy is in the list now. http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: RE: Fastest web framework Date: Tue, 25 Sep 2012 13:52:25 +0300 The post has been updated with two more frameworks (per community request): tornado and web2py. Comments or suggestions are welcome. Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest web framework Date: Sun, 23 Sep 2012 12:19:16 +0300 I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Tarek, Thank you for the response back. Yes, your idea is pretty clear to me. The point is that higher workload you put in your application business logic, repository, backend, whatever... less you will see in final results comparison. This is obvious and we, as technical people, very well understand this (somebody even laugh). The reality is that not all web applications do heavy CPU computations and/or experience IO delays (due to response from database running a query over table that has no index, let say), some use caches, some split jobs to be run in background, some parallel them... I have to state that simple things must perform really fast to give more room for one that are not so. That in turn makes your infrastructure more effective. Some prefer to add a box, some see that a likely to be a problem further it goes. The good thing - you have a choice, you are not locked, and as result you are responsible for the effectiveness of the system you build today and definitely next one. Take care. Andriy Date: Wed, 26 Sep 2012 11:08:19 +0200 From: ta...@ziade.org To: andriy.kornats...@live.com CC: python-list@python.org Subject: Re: Fastest web framework On 9/25/12 3:21 PM, Andriy Kornatskyy wrote: Tarek, With all respect, running benchmark on something that has sleeps, etc is pretty far from real world use case. So I went a little bit different way. That's not a good summary of what the function does. It does not just sleep. It does some I/O and CPU bound tasks. The sleep is here to simulate a blocking I/O call, besides the DB calls. The whole function tries to simulate a real application, unlike printing 'Hello World' - to put the stack under realistic conditions. The multiplication is cached by the processor, but will still push some CPU work on every call. Here is a live demo (a semi real world web application) that comes with wheezy.web framework as a template: http://wheezy.pythonanywhere.com/ I have implemented it in a way that it uses one web framework (wheezy.web) and various template engines (jinja2, mako, tenjin, wheezy.template and wheezy.template with preprocessor)... Please see the following post under `Real World Example` section: http://mindref.blogspot.com/2012/07/python-fastest-template.html Source code here: https://bitbucket.org/akorn/wheezy.web/src/tip/demos/template The real world example shows the difference between template engines implementing the same things. The same applies to web frameworks (more or less depending on your choice). Thanks. Great, thanks for the update ! -- that's cool to bench the template engines, but this is still not what I had in mind. What I had in mind was to try each one of the framework with an application that does things, and see how the whole stack reacts on high load. But I guess we have different goals - wheezy seems really fast, congrats. Cheers Tarek Andriy Date: Mon, 24 Sep 2012 13:50:31 +0200 From: ta...@ziade.org To: python-list@python.org Subject: Re: Fastest web framework On 9/23/12 11:19 AM, Andriy Kornatskyy wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy I would try this with a web app that does more than 'Hello World' You may argue that you're just trying the server stack, but that's not realistic because you don't really measure how the server behaves with a real app. Have a look at https://github.com/mozilla-services/chaussette/blob/master/chaussette/util.py#L188 (setup_bench and teardow_bench have to be run on startup and tear down of the server) I would be curious to see how things goes then Cheers Tarek -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
David / Tarek, I believe you and Tarek are pointing the same things. If we want to get that far, we need, first of all, itemize the functions list and find their correspondences in other frameworks... or provide some script of potential calls to framework internal and translate those call to be specific for each framework. In this case we can profile results, capture benchmarks (e.g. with `timeit`) and figure out something more meaningful... yet point framework developers to attention. Does that sound like a thing you are trying to communicate? Thanks. Andriy Date: Wed, 26 Sep 2012 05:48:48 -0400 Subject: Re: Fastest web framework From: dwightdhu...@gmail.com To: ta...@ziade.org CC: andriy.kornats...@live.com; python-list@python.org to Andriy You can use a framework, however, the function from the framework has to be used, and the parameters utilized by the frameworks functions. It would seem that writing your own witin the main page, or using the original function in place from the framework would run a timeit better. I'll look later, but it seems correct in terms of enhancing the frameworks estimated(OS ops)time to completion. Andriy Kornatskyy 5:39 AM (5 minutes ago) to me David, This makes sense... and probably can pretend to be most accurate. Well, in a higher level language, such as Python, you have to remove layers in order to reduce interpreter completion time. So just the usage of a framework makes you utilize a function that has to be imported, accessed and run before the function completes using the parameters. It might be faster if you just used the function itself, or optimized it. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest template engine
The post has been updated with the following template engines added (per community request): 1. chameleon 2. django 3. web2py Here is a link: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest template engine Date: Sun, 23 Sep 2012 12:24:36 +0300 I have run recently a benchmark of a trivial 'big table' example for various python template engines (jinja2, mako, tenjin, tornado and wheezy.template) run on cpython2.7 and pypy1.9.. you might find it interesting: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
The post has been updated with two more frameworks (per community request): tornado and web2py. Comments or suggestions are welcome. Thanks. Andriy Kornatskyy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest web framework Date: Sun, 23 Sep 2012 12:19:16 +0300 I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Alec While performing benchmark for web2py I noticed a memory leak. It constantly grows and never release it... Thanks. Andriy Kornatskyy Date: Mon, 24 Sep 2012 17:36:25 +1000 Subject: Re: Fastest web framework From: alec.tayl...@gmail.com To: andriy.kornats...@live.com CC: python-list@python.org Can you throw in web2py? Thanks On Sun, Sep 23, 2012 at 7:19 PM, Andriy Kornatskyy andriy.kornats...@live.commailto:andriy.kornats...@live.com wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest template engine
The post has been updated due to comment from Makoto Kuwata (author of tenjin) related to use of optimized version of HTML escape in tenjin templates. I believe Mako and Jinja2 both are using MarkupSafe which serves exactly for that purpose there. The test assert the output is unicode. http://mindref.blogspot.com/2012/07/python-fastest-template.html Thanks. Andriy From: andriy.kornats...@live.com To: python-list@python.org Subject: Fastest template engine Date: Sun, 23 Sep 2012 12:24:36 +0300 I have run recently a benchmark of a trivial 'big table' example for various python template engines (jinja2, mako, tenjin, tornado and wheezy.template) run on cpython2.7 and pypy1.9.. you might find it interesting: http://mindref.blogspot.com/2012/07/python-fastest-template.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Tarek, With all respect, running benchmark on something that has sleeps, etc is pretty far from real world use case. So I went a little bit different way. Here is a live demo (a semi real world web application) that comes with wheezy.web framework as a template: http://wheezy.pythonanywhere.com/ I have implemented it in a way that it uses one web framework (wheezy.web) and various template engines (jinja2, mako, tenjin, wheezy.template and wheezy.template with preprocessor)... Please see the following post under `Real World Example` section: http://mindref.blogspot.com/2012/07/python-fastest-template.html Source code here: https://bitbucket.org/akorn/wheezy.web/src/tip/demos/template The real world example shows the difference between template engines implementing the same things. The same applies to web frameworks (more or less depending on your choice). Thanks. Andriy Date: Mon, 24 Sep 2012 13:50:31 +0200 From: ta...@ziade.org To: python-list@python.org Subject: Re: Fastest web framework On 9/23/12 11:19 AM, Andriy Kornatskyy wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy I would try this with a web app that does more than 'Hello World' You may argue that you're just trying the server stack, but that's not realistic because you don't really measure how the server behaves with a real app. Have a look at https://github.com/mozilla-services/chaussette/blob/master/chaussette/util.py#L188 (setup_bench and teardow_bench have to be run on startup and tear down of the server) I would be curious to see how things goes then Cheers Tarek -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
David, Thank you for your comments. Please see my response inline to your questions. Well, lets break down timing something in a more scientific method approach through questioning. What's your processor speed? Please see environment specification at the end of post. Here is a copy just in case: Client: Intel Core 2 Quad CPU Q6600 @ 2.40GHz × 4 Server: Intel Xeon CPU X3430 @ 2.40GHz x 4 LAN 1 Gb What is the constant temperature of the internals of your system? The server environment temperature is constant: 18C / 64F What OS, and version? Server: Debian Testing, Kernel 3.2.0-3-amd64, Python 2.7.3, uwsgi 1.2.6 Client: Debian Testing, Kernel 3.2.0-3-686-pae What other processes are running? There were used standalone server and client, with minimal to zero CPU/network activities on other processes (both, client and server, were dedicated to test purpose). Thanks. Andriy Kornatskyy Date: Sun, 3 Sep 012 6::6::5 -400 Subject: Re: Fastest web framework From: dwightdhu...@gmail.com To: andriy.kornats...@live.com CC: python-list@python.org Hope I understood you correctly. Well, lets break down timing something in a more scientific method approach through questioning. What's your processor speed? What is the constant temperature of the internals of your system? What OS, and version? What other processes are running? There's a scientific method to what you're benchmarking. There have to be constants, and variables to benchmark with. These will of course vary with other methods of approach with the same code. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Alex, Are you on Python Planet? If not, you might want to syndicate your blog there to reach more of the Python web framework crowd. Thank you for your advise. I will send a request for addition to Python Planet. http://feeds.feedburner.com/MindReference Thanks. Andriy To: python-list@python.org From: acl...@aclark.net Subject: Re: Fastest web framework Date: Sun, 23 Sep 2012 17:25:20 -0400 On 2012-09-23 09:19:16 +, Andriy Kornatskyy said: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Are you on Python Planet? If not, you might want to syndicate your blog there to reach more of the Python web framework crowd. Thanks. Andriy Kornatskyy -- Alex Clark · http://pythonpackages.com -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Accepted. Date: Mon, 24 Sep 2012 17:36:25 +1000 Subject: Re: Fastest web framework From: alec.tayl...@gmail.com To: andriy.kornats...@live.com CC: python-list@python.org Can you throw in web2py? Thanks On Sun, Sep 23, 2012 at 7:19 PM, Andriy Kornatskyy andriy.kornats...@live.commailto:andriy.kornats...@live.com wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Try to see 'Hello World' benchmark as an answer to the question how effective is the framework inside... If computer X boots faster than Y, it means it is more effective in this particular area. If a sportsman runs a distance 1 second faster than other, he got a medal (it is not quite adequate to say if I load sportsman with 50 kilo bag he will not run that fast... just try split the concerns). Thanks. Andriy Subject: Re: Fastest web framework From: mar...@letterboxes.org To: python-list@python.org Date: Mon, 24 Sep 2012 15:42:00 -0400 On Sun, 2012-09-23 at 12:19 +0300, Andriy Kornatskyy wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. The thing I don't like about these benchmarks is.. they tell you which framework is best for writing a trivial 'hello world' application. But no one writes trivial 'hello world' applications. A framework/programming language/software package/what-have-you. Can be really fast for trivial stuff, but perform much less favorably when performing real-world tasks. It's kind of the same argument that's used when people say X computer boots faster than Y computer. That's nice and all, but I spend much more of my time *using* my computer than *booting* it, so it doesn't give me a good picture of how the computers perform. This is why most good benchmarks run a series various tests based on real-world use cases. -a -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
wheezy.web presentation - build modern, efficient web
Here are links to presentation held in Kyiv.Py (Ukraine) on September 22, 2012: wheezy.web introduction a lightweight, high performance, high concurrency WSGI web framework with the key features to build modern, efficient web Download from: https://bitbucket.org/akorn/wheezy.web/downloads/ Files: wheezy.web-introduction.pdf wheezy.web-examine.pdf Hope you find it interesting. Thanks. Andriy Kornatskyy -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
If we take a look at web application we can split it into at least two parts, one that renders things out and the other one that does data extraction, e.g. from database (this is what you are pointing at). If you made a first call to database you get your list and can easily cache it. The next call IS without impact that database call may cause... but you still keep serving pages out... Thanks. Andriy From: r...@panix.com Subject: Re: Fastest web framework Date: Sun, 23 Sep 2012 10:02:28 -0400 To: python-list@python.org In article mailman.1110.1348392023.27098.python-l...@python.org, Andriy Kornatskyy andriy.kornats...@live.com wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. That's a nice comparison, thanks for posting it. One thing that's worth pointing out, however, is that in a real world application, as long as you're using something halfway decent, the speed of the framework is probably not going to matter at all. It's much more likely that database throughput will be the dominating factor. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Few facts that doesn't make it less interesting: (1) the test source code available (2) the test itself is pretty famous (3) you can re-run it (4) or even better supply own that in your believe is 100% relevant Not every project has problem with database performance. Some use caching... and pretty happy. In my case I have got 2x boost of web application performance just by switching to wheezy.template, that simple. Thanks. Andriy To: python-list@python.org From: stefan...@behnel.de Subject: Re: Fastest web framework Date: Sun, 23 Sep 2012 17:50:20 +0200 Roy Smith, 23.09.2012 16:02: Andriy Kornatskyy wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle,�django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. That's a nice comparison, thanks for posting it. One thing that's worth pointing out, however, is that in a real world application, as long as you're using something halfway decent, the speed of the framework is probably not going to matter at all. It's much more likely that database throughput will be the dominating factor. Yes, that makes the comparison (which may or may not be biased towards his own engine) a bit less interesting. Worth keeping this in mind: http://www.codeirony.com/?p=9 Stefan -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Good to know you are in a good humor today. You will be surprised... far not all share your point of view. ;-) Few links for you to stop laughing that loud: http://packages.python.org/wheezy.http/userguide.html#content-cache http://packages.python.org/wheezy.caching/userguide.html#cachedependency Andriy To: python-list@python.org From: breamore...@yahoo.co.uk Subject: Re: Fastest web framework Date: Sun, 23 Sep 2012 18:20:03 +0100 On 23/09/2012 16:50, Stefan Behnel wrote: Roy Smith, 23.09.2012 16:02: Andriy Kornatskyy wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle,�django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. That's a nice comparison, thanks for posting it. One thing that's worth pointing out, however, is that in a real world application, as long as you're using something halfway decent, the speed of the framework is probably not going to matter at all. It's much more likely that database throughput will be the dominating factor. Yes, that makes the comparison (which may or may not be biased towards his own engine) a bit less interesting. Worth keeping this in mind: http://www.codeirony.com/?p=9 Stefan I'd like to say thanks for the link but unfortunately for me, but good news for you (plural), is that I've bust a gut laughing out loud, so I won't :) Oh alright then thanks for the link. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Good to know you are in a good humor today. You will be surprised... far not all share your point of view. ;-) Few links for you to stop laughing that loud: http://packages.python.org/wheezy.http/userguide.html#content-cache http://packages.python.org/wheezy.caching/userguide.html#cachedependency Andriy To: python-list@python.org From: breamore...@yahoo.co.uk Subject: Re: Fastest web framework Date: Sun, 23 Sep 2012 18:20:03 +0100 On 23/09/2012 16:50, Stefan Behnel wrote: Roy Smith, 23.09.2012 16:02: Andriy Kornatskyy wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle,�django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. That's a nice comparison, thanks for posting it. One thing that's worth pointing out, however, is that in a real world application, as long as you're using something halfway decent, the speed of the framework is probably not going to matter at all. It's much more likely that database throughput will be the dominating factor. Yes, that makes the comparison (which may or may not be biased towards his own engine) a bit less interesting. Worth keeping this in mind: http://www.codeirony.com/?p=9 Stefan I'd like to say thanks for the link but unfortunately for me, but good news for you (plural), is that I've bust a gut laughing out loud, so I won't :) Oh alright then thanks for the link. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
Good to know you are in a good humor today. You will be surprised... far not all share your point of view. ;-) Few links for you to stop laughing that loud: http://packages.python.org/wheezy.http/userguide.html#content-cache http://packages.python.org/wheezy.caching/userguide.html#cachedependency Andriy To: python-list@python.org From: breamore...@yahoo.co.uk Subject: Re: Fastest web framework Date: Sun, 23 Sep 2012 18:20:03 +0100 On 23/09/2012 16:50, Stefan Behnel wrote: Roy Smith, 23.09.2012 16:02: Andriy Kornatskyy wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle,�django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9... you might find it interesting: http://mindref.blogspot.com/2012/09/python-fastest-web-framework.html Comments or suggestions are welcome. That's a nice comparison, thanks for posting it. One thing that's worth pointing out, however, is that in a real world application, as long as you're using something halfway decent, the speed of the framework is probably not going to matter at all. It's much more likely that database throughput will be the dominating factor. Yes, that makes the comparison (which may or may not be biased towards his own engine) a bit less interesting. Worth keeping this in mind: http://www.codeirony.com/?p=9 Stefan I'd like to say thanks for the link but unfortunately for me, but good news for you (plural), is that I've bust a gut laughing out loud, so I won't :) Oh alright then thanks for the link. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
The problem is that easy if you have a complete control over what you are caching. Complete control over cache may look a challenging task however with use of cache dependency you can lower it significantly. Take a look here: http://packages.python.org/wheezy.caching/userguide.html#cachedependency If you have a willing to go even further consider take a look at content caching: http://packages.python.org/wheezy.http/userguide.html#content-cache Serving static page out of your data is not that impossible... there are still exceptions, of cause. Thanks. Andriy To: python-list@python.org From: stefan...@behnel.de Subject: Re: Fastest web framework Date: Sun, Sep 2 :: +0 Andriy Kornatskyy, ..2 :: If we take a look at web application we can split it into at least two parts, one that renders things out and the other one that does data extraction, e.g. from database (this is what you are pointing at). If you made a first call to database you get your list and can easily cache it. The next call IS without impact that database call may cause... but you still keep serving pages out... Well, if it was really that easy, you wouldn't be using a database in the first place but static pages, would you? Stefan -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: Fastest web framework
On Sun, Sep 23, 2012 at 5:19 AM, Andriy Kornatskyy andriy.kornats...@live.com wrote: I have run recently a benchmark of a trivial 'hello world' application for various python web frameworks (bottle, django, flask, pyramid, web.py, wheezy.web) hosted in uWSGI/cpython2.7 and gunicorn/pypy1.9 There are other considerations that must be made when running a 'hello world'. -It is a basic string, but no numerical benchmarks. The basic string in return was chosen to benchmark framework code in processing a simple thing and measure the overhead related. In other words how effective the framework is inside. -You've overlooked the fact that different OS's have other processes at work, which need to be looked at -and a function which performed several tasks(a string, and numerical), and then returned the result on seveal operating systems, with non-essential processes turned off There were minimal processes running on both client and server, and even if some have had CPU/network activity it was not so important to the workload both client and server experienced due to test performed. Hope I understood you correctly. Thanks. Andriy -- http://mail.python.org/mailman/listinfo/python-list
