Re: Article on the future of Python
On Wed, Sep 26, 2012 at 3:16 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wed, 26 Sep 2012 14:10:28 +1000, Chris Angelico wrote: The flip side to node.js is pyjs. After the ham-fisted, nasty way pyjamas project was hijacked this year, I'm not entirely sure I'd want to touch it with a fifty-foot pole. http://technogems.blogspot.com.au/2012/05/pyjamas-hijacked.html Any pajamas users here want to comment on the fallout? Is the project alive, dead, or walking dead? That is true, but the concept is still around - that you can write your code in some other language and compile to js. Personally, I'd rather just write my js directly, and use Python to write Python code, but I'm sufficiently multilingual to be able to do that. If you know only 1-2 languages, there's (short-term) benefit in using them for more tasks. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Chris Angelico ros...@gmail.com writes: That is true, but the concept is still around - that you can write your code in some other language and compile to js. http://www.haskell.org/haskellwiki/The_JavaScript_Problem -- http://mail.python.org/mailman/listinfo/python-list
Re: google api and oauth2
If you are writing a desktop application, read this: https://developers.google.com/accounts/docs/OAuth2#clientside You mean https://developers.google.com/accounts/docs/OAuth2#installed? Your link discusses client side browser implementations. I'd be curious to know the shortcomings of sanction in the context of installed apps. My original intent was to provide a server flow implementation. If the installed flow isn't too much of a change (doesn't seem like it would be, according to the docs, it's how the code is retrieved by the application), I'd happily add it in or take a patch to cover it. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Le mercredi 26 septembre 2012 01:34:01 UTC+2, 8 Dihedral a écrit : Grant Edwards於 2012年9月26日星期三UTC+8上午2時25分31秒寫道： On 2012-09-25, Martin P. Hellwig martin.hell...@gmail.com wrote: On Tuesday, 25 September 2012 09:14:27 UTC+1, Mark Lawrence wrote: Hi all, I though this might be of interest. http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-python I glanced over the article but it seems to me another 'I am afraid this is not the silver bullet I wanted it to be' article Strange. I didn't get that _at_all_ from the article. To me it was expressing concern about what happens when the range of niches where Python is a good solution falls below a certain critical mass -- will the Python Community start to stagnate because it isn't attacting new developers in the quantity or diversity that it used to... -- Grant Edwards grant.b.edwardsYow! Alright, you!! at Imitate a WOUNDED SEAL gmail.compleading for a PARKING SPACE!! I don't think so in 201X. The uni-code support for users and clients all over the world should not be taxed by WINTEL only in multi-language support under the OS. I am glad to see a lot smart phones or pads are fostering applications in various languages to help the IT industry keeping growing and expanding to those regeions covered by wirelees digital communications with devices priced in the range 200 to 12000 usd. Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. --- From nnn: ...schools moving towards Python... I do not know what schools covers. Interestingly (and unfortunately), it just becomes a no-tool for those who wish to teach Unicode. Or, in one sense, it just become one! PS I spent my last days with XeTeX and unicode-math. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
You can Plonk my dick bitches. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Stop feeding the trolls (Was: which a is used?)
On Wed, Sep 26, 2012 at 3:06 AM, Dwight Hutto dwightdhu...@gmail.com wrote: You can Plonk my dick bitches. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com +5.75 -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. For the first time in Python's history, Python on 32-bit systems handles strings containing Supplementary Multilingual Plane characters correctly, and it does so without doubling or quadrupling the amount of memory every single string takes up. Strings are ubiquitous in Python -- every module, every variable, every function, every class is associated with at least one and often many strings, and they are nearly all ASCII strings. The overhead of using four bytes instead of one for every string is considerable. Python finally has correct unicode handling for characters beyond the BMP, and it does so with more efficient strings that potentially use as little as one quarter of the memory that they otherwise would use, at the cost of a small slowdown in the artificial and unrealistic case that you repeatedly create millions of strings and then just throw them away immediately. Most realistic cases of string handling are unchanged in speed, either trivially faster or trivially slower. The real saving is in memory. According to wxjmfauth, this has killed unicode. Judge for yourself his credibility. The best I can determine, he believes this because Americans aren't made to suffer for using mostly ASCII strings. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. *plonk* -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman et...@stoneleaf.us wrote: wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. Well, we can all use american as a standard, or maybe you'd prefer to borrow my Latin for Idiots handbook. But then again google has a Universal Communicator going, so, does it matter? -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, Sep 26, 2012 at 5:39 PM, Dwight Hutto dwightdhu...@gmail.com wrote: On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman et...@stoneleaf.us wrote: wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. Well, we can all use american as a standard, or maybe you'd prefer to borrow my Latin for Idiots handbook. But then again google has a Universal Communicator going, so, does it matter? Never in the field of human discussion has there been so much reason for so many to plonk so few. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
regular expression : the dollar sign ($) work with re.match() or re.search() ？
I only know the dollar sign ($) will match a pattern from the end of a string,but which method does it work with ,re.match() or re.search() ？ -- http://mail.python.org/mailman/listinfo/python-list
Re: regular expression : the dollar sign ($) work with re.match() or re.search()
iMath writes: I only know the dollar sign ($) will match a pattern from the end of a string, but which method does it work with, re.match() or re.search() It works with both. With re.match, the pattern has to match at the start of the string _and_ the $ has to match the end of the string (or a line); re.search scans the string until it finds a suitable start. What was the weird character that you used as a question mark? I removed them because they confuse the newsreader I use. -- http://mail.python.org/mailman/listinfo/python-list
Re: regular expression : the dollar sign ($) work with re.match() or re.search()
On Wed, Sep 26, 2012 at 5:48 PM, Jussi Piitulainen jpiit...@ling.helsinki.fi wrote: What was the weird character that you used as a question mark? I removed them because they confuse the newsreader I use. It appears to be Unicode Character 'FULLWIDTH QUESTION MARK' (U+FF1F). Normally I'd be inclined to simply use U+003F instead, but hey, it's a question mark still. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Well, we can all use american as a standard, or maybe you'd prefer to borrow my Latin for Idiots handbook. But then again google has a Universal Communicator going, so, does it matter? Never in the field of human discussion has there been so much reason for so many to plonk so few. Plonk it if you want. Your homosexual ideologies have no effect on me. Butt, back to the discussion, there are quite a few ways to encode, as well as translate code. Plonk it in your mouth, and let the nut hairs tickle your throat. ChrisA -- http://mail.python.org/mailman/listinfo/python-list -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/26/2012 2:35 AM, wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. Python 3.3 is the first version that handles the full unicode character set correctly on all platforms. If anything, it will make unicode more alive and Python better suited for international applications. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
ANN: eGenix mxODBC Connect - Python Database Interface 2.0.1
ANNOUNCING eGenix.com mxODBC Connect Python Database Interface Version 2.0.1 mxODBC Connect is our commercially supported client-server product for connecting Python applications to relational databases in a truly cross-platform way. This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mxODBC-Connect-2.0.1-GA.html INTRODUCTION The mxODBC Connect Database Interface for Python allows users to easily connect Python applications to all major databases on the market today in a highly portable, convenient and secure way. Python Database Connectivity the Easy Way - Unlike our mxODBC Python extension, mxODBC Connect is designed as client-server application, so you no longer need to find production quality ODBC drivers for all the platforms you target with your Python application. Instead you use an easy to install Python client library which connects directly to the mxODBC Connect database server over the network. This makes mxODBC Connect a great basis for writing cross-platform multi-tier database applications and utilities in Python, especially if you run applications that need to communicate with databases such as MS SQL Server and MS Access, Oracle Database, IBM DB2 and Informix, Sybase ASE and Sybase Anywhere, MySQL, PostgreSQL, SAP MaxDB and many more, that run on Windows or Linux machines. Ideal for Database Driven Client Applications - By removing the need to install and configure ODBC drivers on the client side and dealing with complicated network setups for each set of drivers, mxODBC Connect greatly simplifies deployment of database driven client applications, while at the same time making the network communication between client and database server more efficient and more secure. For more information, please have a look at the mxODBC Connect product page, in particular, the full list of available features. For more information, please see the product page: http://www.egenix.com/products/python/mxODBCConnect/ NEWS The 2.0.1 release of mxODBC Connect includes the following enhancements and fixes: API Enhancements * Added support for returning SQL Server TIME columns as time value instead of as string. * Added a work-around to prevent truncation warnings with the SQL Server ODBC driver when using .executemany(..., direct=1). Thanks for Michael Bayer. Server Enhancements --- * Upgraded the mxODBC used in the server to version mxODBC 3.2.1. Client Enhancements --- * Added egenix-mx-base dependency to mxODBC Connect egg files. Misc * Added hint on how to work with REF CURSORS in Oracle stored procedures. Thanks to Etienne Desgagné. mxODBC Connect 2.0.0 was released on 2012-08-20. These are the highlights of the new release: mxODBC Connect 2.0 Enhanced API --- * mxODBC Connect Server now uses mxODBC 3.2 internally and makes its API available in the mxODBC Connect Client. This is a major step forward from the mxODBC 3.0 version used in mxODBC Connect Server 1.0. * mxODBC Connect Client comes with all the mxODBC enhancements, including: - connection and cursor objects can be used as context managers - adjustable parameter styles (qmark or named) - connection .autocommit attribute to easily switch on autocommit - adjustable timestamp resolution - new possibilities to set connection and cursor options to adjust the ODBC objects to your application needs, e.g. set a connection read-only or set a query timeout - adjustable decimal, datetime and string formats - adjustable warning format to be able to handle server warnings without client interaction - greatly improved result set scrolling support - Unicode support for all catalog methods - Access to additional result set meta data via cursor.getcolattribute() Updated Compatibility - * The server now features all the ODBC driver compatibility enhancements provided by mxODBC 3.2, including improved and updated support for MS SQL Server Native Client, Oracle Instant Client, Sybase ASE, IBM DB2, Teradata and Netezza. * Native Windows x64 builds with signed executables and a tray app rewritten in C are available for Windows 2008R2, Vista and 7 x64, so you can benefit from better performance, fewer UAC dialogs and smaller memory footprint. Asynchronous Execution -- * mxODBC Connect Client now integrates directly with gevent, allowing
Re: google api and oauth2
On Wed, Sep 26, 2012 at 11:45 AM, Demian Brecht demianbre...@gmail.com wrote: If you are writing a desktop application, read this: https://developers.google.com/accounts/docs/OAuth2#clientside You mean https://developers.google.com/accounts/docs/OAuth2#installed? Your link discusses client side browser implementations. Ah yes, I made a mistake in linking displayed url and scrolled position. I'd be curious to know the shortcomings of sanction in the context of installed apps. My original intent was to provide a server flow implementation. If the installed flow isn't too much of a change (doesn't seem like it would be, according to the docs, it's how the code is retrieved by the application), I'd happily add it in or take a patch to cover it. I tried out sanction from a python shell. In an installed application, the user can either start a little web server to handle redirect_uri, or pass in the special value urn:ietf:wg:oauth:2.0:oob to have the authorization code be shown in a text field in the browser (all of this is for google, I have no idea how other implementations or the oauth spec differ). At the moment, the auth_uri function gives out a URI and leaves it up to the client to deal with it however it likes. The library could provide a function (let's call it drive_auth) to drive the entire process: start a little web server on any available port, give a url to that server as redirect_uri, then start the user's web browser to connect to the authentication endpoint. The embedded web server will need to handle redirect_uri to grab the authorization code, generate an HTML response that will close the browser window (or instruct the user to do so), and then stop itself. For GUI applications which can embed a web browser widget, there is no need to start a separate web browser application. To support such applications, the drive_auth function can take a callback argument to navigate to a particular URL. Then the client applications can hook in their particular GUI toolkit, or just pass in webbrowser.open if they like. All this may be beyond the intended scope of your library. -- regards, kushal -- http://mail.python.org/mailman/listinfo/python-list
Looking for pointers/suggestion - how to make a webbrowser with these restriction?
Hi, all, It is kind of a MacGyver question. I am just looking for some general suggestions/pointer. First let me first describe the development environment I am in: it is a locked down WinXP PC with limited development tools and libraries. At my disposal I have python 2.6 , webkit 5.33 dll, wx 2.8 and probably a V8 dll. No visual studio or any C/C++ compiler. Do not have admin right. So given these existing ingredients, is it possible to build a rudimentary web browser using python as a glue language? What will be the main challenge/bottleneck in this sort of project? In particular how can I hook up V8 and Webkit? I have some working experience with Win32 APIs, so you may throw some low level stuff at me if needed. :-) Cheers -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 26/09/2012 05:10, Chris Angelico wrote: On Wed, Sep 26, 2012 at 10:54 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: SQL? ... it's time to sell your shares in Oracle. Ehh, I wouldn't be investing in Oracle, but that's more because I think free RDBMSes like PostgreSQL outshine it. And this is even more true of MS SQL Server - this last week I've been researching options for moving work's services to the cloud, and SQL Server licenses cost ridiculous amounts (per month or per hour); what do you get for that money that you can't get from Postgres? ChrisA Maybe true but do free RDBMes have the sales and marketing budgets that effectively shot down Ingres? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 26/09/2012 07:35, wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. jmf Why do you keep repeating this rubbish when you've already been shot to pieces? Don't you know when it's time to make sure that you're safely strapped in and reach for and use the release button for the ejector seat. Further for somebody who is apparently up in the high tech world, why are you using a gmail account and hence sending garbage in more ways than one to mailing lists like this? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: regular expression : the dollar sign ($) work with re.match() or re.search() ？
iMath wrote:
I only know the dollar sign ($) will match a pattern from the
end of a string,but which method does it work with ,re.match() or
re.search() ？
Why not try it out in the interactive interpreter? Here's the deluxe
version:
def demo(pattern=mid$, texts=[start mid end, start mid, mid end,
mid], matchers=[re.match, re.search]):
... print pattern:, pattern
... for text in texts:
... for matcher in matchers:
... name = matcher.__name__
... print u\N{CHECK MARK} + name if matcher(pattern,
text) else ( *(len(name)+1)),
... print repr(text)
...
demo()
pattern: mid$
'start mid end'
✓search 'start mid'
'mid end'
✓match ✓search 'mid'
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 26/09/2012 08:44, Chris Angelico wrote: On Wed, Sep 26, 2012 at 5:39 PM, Dwight Hutto dwightdhu...@gmail.com wrote: On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman et...@stoneleaf.us wrote: wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. Well, we can all use american as a standard, or maybe you'd prefer to borrow my Latin for Idiots handbook. But then again google has a Universal Communicator going, so, does it matter? Never in the field of human discussion has there been so much reason for so many to plonk so few. ChrisA I tried to make a play on that some days ago and failed dismally. Thanks for putting me out of my misery :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, Sep 26, 2012 at 6:34 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: Further for somebody who is apparently up in the high tech world, why are you using a gmail account and hence sending garbage in more ways than one to mailing lists like this? I use gmail too, largely because I prefer to keep mailing list posts off my primary account. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Why do you keep repeating this rubbish when you've already been shot to pieces? I still feel intact, so whatever little shards of pain you intended to emit were lost on my ego. Don't you know when it's time to make sure that you're safely strapped in and reach for and use the release button for the ejector seat. You ain't shot down shit, but your own reputation. Look at the full conversation. Further for somebody who is apparently up in the high tech world, why are you using a gmail account and hence sending garbage in more ways than one to mailing lists like this? Um, using gmail instead of reinventing the wheel is now appropriate to you? -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
I tried to make a play on that some days ago and failed dismally. That's the fucking understatement of the year. Thanks for putting me out of my misery :) -- No prob. Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
mimetypes.guess_type broken in windows on py2.7 and python 3.X
Hi,
I'm still experiencing the pleasure of migrating legacy code from Python
2.6. to 2.7 which I expected to be much less painful.
(In fact migration on Linux is rather smooth, but Windows is another story)
Let's take the simple command
import mimetypes
print mimetypes.guess_type('a.jpg')
The result an old pythons ( 2.7)
is ('image/jpeg', None)
Ther result on non windows platform is
for python 2.7 / 3.X is the same
However. The result for 2.7 / 3.x on windows is now
('image/pjpeg', None) # pjpeg instead of jpeg
On Windows many file suffixes will report wrong mime types.
The problem is know for about two years.
http://bugs.python.org/issue10551
The main reason is, that under wWindows default values are
fetched from Python and then 'updated' mime-types are
fetched from the Windows registry.
The major problem is, that almost ALL windows PCs have BROKEN mime
types. so the good predefined mime types are just replaced with broken
MS mime types.
I wonder how many applications, that will try to migrate to 2.7 / 3.0
will fail due to this incompatibility in the mimetypes library
There is a workaround (but first people have to detect the problem and
to find it):
Add these two lines somewhere in your code BEFORE any other imported
library might have called a mimetypes function
import mimetypes
mimetypes.init([])
I still wonder if it wouldn't be better to have the default behaviour of
2.7 / 3.0 on windows such, that all the users who're not aware of this
issue will not have their code broken.
My suggestion for windows would be to have following default behaviour:
- !st read the mimetypes from the registry if possible
- 2nd read the Python default mimetypes and override the
'broken' MS definitions
Only if a user explicitely calls mimetypes.init() they would have
differente behaviour.
The new behaviour breaks portability of Python code between Windows and
Linux and I think the attempt should be to be as cross platform as
possible. and not to be. At least one of the reasons why I use pythin
is, that it allows to be rather cross-platform
An alternative suggestion could be to never read the registry or
/etc/mimetypes by default.
What would definitely be rather important is add a big warning in the
documentation and a recommendation of how to write cross platform
compatible code.
Somebody developing on Linux might not even know, that the code will not
work on windows jsst because of this tiny issue.
The unfortunate fact, that this issue was not fixed two years ago means,
that perhaps meanwhile some code is out, that relies on the current
behaviour. However I'm not sure, that anybody relies on the fact, that
code will not work the same way on windows and on Linux.
Any thoughts?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 26/09/2012 09:47, Dwight Hutto wrote: I tried to make a play on that some days ago and failed dismally. That's the fucking understatement of the year. You remind me of the opening to the song Plaistow Patricia by Ian Dury and the Blockheads. Thanks for putting me out of my misery :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
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: Article on the future of Python
That's the fucking understatement of the year. You remind me of the opening to the song Plaistow Patricia by Ian Dury and the Blockheads. Make a modern day/mainstream reference, and maybe someone will get it. Thanks for putting me out of my misery :) Again, no problem...anytime buddy. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- 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: Article on the future of Python
On Tuesday, 25 September 2012 21:05:01 UTC+5:30, Steven D'Aprano wrote: On Tue, 25 Sep 2012 09:26:19 -0400, Kevin Walzer wrote: On 9/25/12 4:15 AM, Mark Lawrence wrote: Hi all, I though this might be of interest. http://www.ironfroggy.com/software/i-am-worried-about-the-future-of- python Interesting article, but the comments of those who say the only language I need to know is Python strike me as a bit limited. If this is the case, then Python can never be moved forward, because it is written in C. Incorrect. IronPython in C#. Jython is written in Java. CLPython is written in Lisp. Berp and HoPe are written in Haskell. Nuitka is written in C++. Skulpt is written in Javascript. Vyper is written in Ocaml. PyPy is written in RPython. Some of those Python compilers are obsolete, unmaintained or experimental. Others are not. But either way, it is certainly not true that Python is written in C. One specific Python compiler happens to be written in C, that is all. I program in Python, C, Objective C, JavaScript, Tcl, AppleScript, and I'm learning Perl. Python could *not* handle all the domains I target in my projects. Unless you are writing code that operates on the bare metal (device drivers, operating system kernels) Python probably *could*, even if it doesn't *yet*. PyPy now allows you to write real-time video processing filters in pure Python: http://morepypy.blogspot.com.au/2011/07/realtime-image-processing-in-python.html And if performance was irrelevant, you could even write an operating system in Python. A really slow, painful operating system, but still an operating system. That's what I plan to do. But it will be converted to C/C++ Given a sufficiently smart compiler, and sufficiently powerful libraries, or sufficiently low expectations, pretty much any programming language can do anything any other language can do. Almost all of them are Turing complete. But of course, in practice languages differ in their power and capabilities. For instance: if I want to access Mac-native functionality via Tkinter that isn't currently available in the library, That isn't currently available part is precisely what I'm talking about. Just because it's not available now doesn't mean it can't be made available. I can understand loving the language and wanting to work just in the language, but it's another thing entirely to call Python the One Language to Rule Them All. (That's C, because all other languages are implemented in it. :-) ) I see your smiley, but that is factually incorrect. Not all compilers or interpreters are written in C. Many languages are self-hosted, that is, they are written in themselves, using some clever bootstrapping techniques. C is neither the most powerful, the oldest, the best, or the most fundamental language around. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Le mercredi 26 septembre 2012 09:23:47 UTC+2, Steven D'Aprano a écrit : On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. Steven, you are correct. But the price you pay for this is extremely high. Now, practically all characters are affected, espacially those *in* the Basic *** Multilingual*** Plane, these characters used by non American user (No offense here, I just use this word for ascii/latin-1). I'm ready to be considered as an idiot, but I'm not blind. As soon as I tested these characters, Py3.3 performs really badly. It seems to me it is legitimate to consider, there is a serious problem here. - I'm speaking about language characters, one should speak about scripting characters. - Obviously affected are not only the language characters, but all characters, typographical signs, polytonic Greek, up to mathematical Bold italic sans serif, Latin, uppercase, logically because all the code points are equivalent. Many people are commmenting, I have the feeling, I'm the only one who tested this. It is not necessary to dive in the Python code, understanding all this characters stuff is enough. And I am sorry, just saying if you are not happy, switch back to Python 2.7 or use Ruby (you know where you can read it) is in my mind not a correct answer. It only reflect a yes, there is a problem, but... Do not worry about me, I attempt to keep a neutral eye. It is my point of view (and facts). I will not open a blog with a Python blah, blah, blah. jmf For the first time in Python's history, Python on 32-bit systems handles strings containing Supplementary Multilingual Plane characters correctly, and it does so without doubling or quadrupling the amount of memory every single string takes up. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
they are written in themselves, using some clever bootstrapping techniques. C is neither the most powerful, the oldest, the best, or the most fundamental language around. Would you recommend Assembly, because C just becomea macros of Assembly, or better yet machine language, which is line for line procedural Assembly for the processor instruction set working in line with the OS.. -- Best Regards, David Hutto CEO: http://www.hitwebdevelopment.com -- http://mail.python.org/mailman/listinfo/python-list
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 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
Re: Fastest web framework
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: Article on the future of Python
On Wed, Sep 26, 2012 at 7:31 PM, wxjmfa...@gmail.com wrote: you are correct. But the price you pay for this is extremely high. Now, practically all characters are affected, espacially those *in* the Basic *** Multilingual*** Plane, these characters used by non American user (No offense here, I just use this word for ascii/latin-1). I'm ready to be considered as an idiot, but I'm not blind. As soon as I tested these characters, Py3.3 performs really badly. It seems to me it is legitimate to consider, there is a serious problem here. We've been over this thread. The only reason you're counting 3.3 as worse is because you're comparing against a narrow build of Python 3.2. Narrow builds are **BUGGY** and this needed to be resolved. When you compare against a wide build, semantics of 3.2 and 3.3 are identical, and then - and ONLY then - can you sanely compare performance. And 3.3 stacks up much better. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 09/26/2012 10:32 AM, Mark Lawrence wrote: On 26/09/2012 05:10, Chris Angelico wrote: On Wed, Sep 26, 2012 at 10:54 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: SQL? ... it's time to sell your shares in Oracle. Ehh, I wouldn't be investing in Oracle, but that's more because I think free RDBMSes like PostgreSQL outshine it. And this is even more true of MS SQL Server - this last week I've been researching options for moving work's services to the cloud, and SQL Server licenses cost ridiculous amounts (per month or per hour); what do you get for that money that you can't get from Postgres? ChrisA Maybe true but do free RDBMes have the sales and marketing budgets that effectively shot down Ingres? Nope. They don't have budget to shoot down Ingres. Also, free RDBMs do not engage in dubious promise-and-dont-deliver- then-ask-more-money sales policies that got Oracle kicked out of US Government simplified buying processes. You can get only so far using sales. At some point you have to deliver. Hannu -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for pointers/suggestion - how to make a webbrowser with these restriction?
On Wed, Sep 26, 2012 at 6:23 PM, Anthony Kong anthony.hw.k...@gmail.com wrote: Hi, all, It is kind of a MacGyver question. I am just looking for some general suggestions/pointer. First let me first describe the development environment I am in: it is a locked down WinXP PC with limited development tools and libraries. At my disposal I have python 2.6 , webkit 5.33 dll, wx 2.8 and probably a V8 dll. No visual studio or any C/C++ compiler. Do not have admin right. XP shouldn't stop you adding another program, even without admin rights. Maybe not a classic web browser, but something uber-thin like HTMLayout [1], though it's not FOSS (it's free for non-commercial use though). It's perhaps too thin for you, but start by loading that up and see how it goes. So given these existing ingredients, is it possible to build a rudimentary web browser using python as a glue language? What will be the main challenge/bottleneck in this sort of project? In particular how can I hook up V8 and Webkit? I have some working experience with Win32 APIs, so you may throw some low level stuff at me if needed. :-) Unless someone else has done it already, you're probably going to have to do some C++ work to embed V8 inside Python. It's not difficult but will need to be done. Webkit is another pile of work. By the time you're done, you'll most likely have written a whole web browser (minus the decades of experience in performance, security vulnerabilities, etc), and it'll probably have problems with your lack of admin rights. What are your actual requirements? What can't you do? There are some really REALLY insane possibilities you could try. Can you install PuTTY [2] and Xming [3], and ssh to a Linux box to run a web browser? (See, I told you it was insane.) ChrisA [1] http://www.terrainformatica.com/htmlayout/ [2] http://www.putty.org/ [3] http://sourceforge.net/projects/xming/ -- 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: Looking for pointers/suggestion - how to make a webbrowser with these restriction?
Hi, Chris, Thanks for your reply. I really do not have any requirement. It is more a curiosity question (not work related). I'd like to find out how python can be used to 'glue' all these moving parts together. Performance and security are definitely not a concern as it is just a toy idea/project. Cheers -- http://mail.python.org/mailman/listinfo/python-list
Re: Need to archive a MySQL database using a python script
On 26/09/12 01:17:24, bruceg113...@gmail.com wrote: Python Users Group, I need to archive a MySQL database using a python script. I found a good example at: https://gist.github.com/3175221 The following line executes however, the archive file is empty. os.popen(mysqldump -u %s -p%s -h %s -e --opt -c %s | gzip -c %s.gz % (user,password,host,database,database+_+filestamp)) Where: User = “someUser” password = “somePassword” host = “someRemote.database.server” database = “someDatabase” If I execute mysqldump from the command line, an archive is created. Using Python 2.6 and MySQL-python-1.2.2.win32-py2.6 (MySQLdb) Mysql-5.5.27 from the command line. Any ideas? * If there are shell meta characters in the password, you'd have need to use single quotes, as in -p'%s'. Actually, that's true for any of the parameters, but the password is one most likely to contain punctuation characters. * You could try print(mysqldump -u %s -p%s -h %s -e --opt -c %s | gzip -c %s.gz % (user,password,host,database,database+_+filestamp)) and if the result looks okay, copy and paste it to the command line (do not retype; use copy and paste) and see if it works. * In your script, add a line os.popen(monty_python) This should produce an error message. If it doesn't, find out why. * Check the timestamp of your empty output file. If it was created yesterday, then maybe your script is now writing its file in another directory and you're looking at the output of yesterday's test. Hope this helps, -- HansM -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Le mercredi 26 septembre 2012 10:35:04 UTC+2, Mark Lawrence a écrit : On 26/09/2012 07:35, wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. jmf Why do you keep repeating this rubbish when you've already been shot to pieces? Don't you know when it's time to make sure that you're safely strapped in and reach for and use the release button for the ejector seat. Further for somebody who is apparently up in the high tech world, why are you using a gmail account and hence sending garbage in more ways than one to mailing lists like this? -- Cheers. Mark Lawrence. At least when the others are sending a msg containing non asii characters. I see them correctly. When you send such a text, I'm only able to see something like this (your_string): import fourbiunicode for c in your_string: ... fourbiunicode.FrenchNames[c] ... 'LETTRE MINUSCULE LATINE TRÉMA' POINT D'INTERROGATION RENVERSÉ 'FRACTION UN DEMI' You have all the elements to reconstruct what is happening. (Notice, I'm not a Unicode illiterate) jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Le mercredi 26 septembre 2012 10:13:58 UTC+2, Terry Reedy a écrit : On 9/26/2012 2:35 AM, wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. Python 3.3 is the first version that handles the full unicode character set correctly on all platforms. If anything, it will make unicode more alive and Python better suited for international applications. -- Terry Jan Reedy Remember the TeX discussion a few days ago? You are always selling the same argument. Py3.3 is the only computer language I'm aware of which is maltreating Unicode in such a way. After all, if replacing a Nabla operator in a string take 10 times more times in Py33 than in Python32, it takes 10 times more . There is nothing more to say. I proposed to make some tests with the characters used by the IMPRIMERIE NATINALE, I can now suggest to make some tests with random texts exceprt form the Guide du typographe romand. What? Never heard from these? Do not worry too much. The corporates (software producers) and the foundries know these documents. Finally, all in all, it's no a suprise, end users are sticking with these products. I'm not complaining, only disappointed. jmf (Time to go back to TeX) -- http://mail.python.org/mailman/listinfo/python-list
[python-list] python application file format
Hello all, What do people recommend for a file format for a python desktop application? Data is complex with 100s/1000s of class instances, which reference each other. Write the file with struct module? (Rebuild object pointers, safe, compact, portable, not expandable without reserved space) Use cPickle with a module/class whitelist? (Can't easily port, not entirely safe, compact enough, expandable) Use JSON or similar? (Rebuild object pointers, portable, expandable, size?) Any advice is greatly appreciated! -- http://mail.python.org/mailman/listinfo/python-list
Re: [python-list] python application file format
On Wednesday, 26 September 2012 18:29:14 UTC+5:30, Benjamin Jessup wrote: Hello all, What do people recommend for a file format for a python desktop application? Data is complex with 100s/1000s of class instances, which reference each other. Write the file with struct module? (Rebuild object pointers, safe, compact, portable, not expandable without reserved space) Use cPickle with a module/class whitelist? (Can't easily port, not entirely safe, compact enough, expandable) Use JSON or similar? (Rebuild object pointers, portable, expandable, size?) Any advice is greatly appreciated! JSON is generally used for configuration. -- http://mail.python.org/mailman/listinfo/python-list
Re: new-style class or old-style class?
On Tuesday, 25 September 2012 20:14:05 UTC+5:30, Jayden wrote: In learning Python, I found there are two types of classes? Which one are widely used in new Python code? Is the new-style much better than old-style? Thanks!! Next time just Google your questions. :-) Good luck with Python -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
In article mailman.1421.1348653712.27098.python-l...@python.org, Hannu Krosing ha...@krosing.net wrote: You can get only so far using sales. At some point you have to deliver. But, by that time, the guy who closed the sale has already cashed his bonus check, bought his new BMW, and moved on to another company. And around that time, some poor schmuck of a dev manager is telling his team what the sales guy sold. And that they have 12 weeks to design, build, and deliver it. -- http://mail.python.org/mailman/listinfo/python-list
Re: new-style class or old-style class?
In article 2e8a9e88-9e7e-43f7-a070-ea9054e62...@googlegroups.com, Jayden jayden.s...@gmail.com wrote: In learning Python, I found there are two types of classes? Which one are widely used in new Python code? Is the new-style much better than old-style? Thanks!! If you're just learning Python 2.x, you might as well use new-style classes, since that's what all classes are in 3.x. On the other hand, if you're just learning, it probably doesn't matter which kind you use. Until you get into some pretty sophisticated stuff, you won't notice any difference between the two. On the third hand, all it takes to create a new-style class is to have it inherit from object. It's no big deal to write class Foo(object): instead of just class Foo: so you might as well use new-style classes :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 26/09/2012 10:31, wxjmfa...@gmail.com wrote: I'm ready to be considered as an idiot, but I'm not blind. People here have seen enough of your writings to know that you're not an idiot. I'm feeling far too polite right now to state what they actually know about you. As soon as I tested these characters, Py3.3 performs really badly. It seems to me it is legitimate to consider, there is a serious problem here. Your tests (for the lack of a better term) have been repeatedly shot to pieces, refuted, you've shown nothing at all to indicate that Python 3.3 performs really badly. Many people are commmenting, I have the feeling, I'm the only one who tested this. It is not necessary to dive in the Python code, understanding all this characters stuff is enough. Complete dross from a person who seems to know as much about the combination of Python 3.3 and unicode as Hitler, Stalin and Pol Pot amongst others knew about human rights. -- Cheers. Mark Lawrence. -- 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: Article on the future of Python
On 26/09/2012 14:01, Roy Smith wrote: In article mailman.1421.1348653712.27098.python-l...@python.org, Hannu Krosing ha...@krosing.net wrote: You can get only so far using sales. At some point you have to deliver. But, by that time, the guy who closed the sale has already cashed his bonus check, bought his new BMW, and moved on to another company. And around that time, some poor schmuck of a dev manager is telling his team what the sales guy sold. And that they have 12 weeks to design, build, and deliver it. How long did you just say??? I promised it in 8 weeks, not 12 you complete moron :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/26/2012 2:11 AM, Dwight Hutto wrote: Well, we can all use american as a standard, or maybe you'd prefer to borrow my Latin for Idiots handbook. But then again google has a Universal Communicator going, so, does it matter? Never in the field of human discussion has there been so much reason for so many to plonk so few. Plonk it if you want. Your homosexual ideologies have no effect on me. Butt, back to the discussion, there are quite a few ways to encode, as well as translate code. You remind me of a little kid. When anything doesn't go your way, we revert to homosexual comments (who said anything about homosexual anyway), and you keep bringing up this whole nut hair deal. I think it's you leaning that way buddy, especially since most of us on here are guys. Plonk it in your mouth, and let the nut hairs tickle your throat. Take your trash somewhere else. You've provided nothing in terms of good feedback or responses, and I doubt you will provide more than insults. PS: Anyone know if rantingrik had relatives? ;) ChrisA -- http://mail.python.org/mailman/listinfo/python-list -- Take care, Ty http://tds-solutions.net The aspen project: a barebones light-weight mud engine: http://code.google.com/p/aspenmud He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/25/12 11:35 AM, Steven D'Aprano wrote: IronPython in C#. Jython is written in Java. CLPython is written in Lisp. Berp and HoPe are written in Haskell. Nuitka is written in C++. Skulpt is written in Javascript. Vyper is written in Ocaml. PyPy is written in RPython. Some of those Python compilers are obsolete, unmaintained or experimental. Others are not. But either way, it is certainly not true that Python is written in C. One specific Python compiler happens to be written in C, that is all. Apart from IronPython, what constituency do these alternative implementations of Python have that would raise them above the level of interesting experiments? -- Kevin Walzer Code by Kevin http://www.codebykevin.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 26/09/2012 14:31, Littlefield, Tyler wrote: PS: Anyone know if rantingrik had relatives? ;) I say steady on old chap that's just not cricket. I've been known to have a go at rr in the past for good reasons, but when he gets stuck into Tkinter he is an extremely useful contributor. I certainly prefer him to Xah Lee, who's attempts at improving Python documentation were beautifully torn to pieces here, IIRC by Ethan Furman, apologies to him and the actual author if I'm incorrect. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, Sep 26, 2012 at 10:19 PM, wxjmfa...@gmail.com wrote: You are always selling the same argument. Py3.3 is the only computer language I'm aware of which is maltreating Unicode in such a way. You mean, the only computer language that represents Unicode characters as integers, and then stores them as an array of 8-bit, 16-bit, or 32-bit numbers depending on the highest codepoint? No, it's not. I can disprove your statement with a single counterexample, but it's entirely possible and (IMHO) likely that there are others too: http://pike.lysator.liu.se/generated/manual/modref/ex/predef_3A_3A/String/width.html Pike stores strings in largely the same way Python 3.3 does. Pike strings are immutable and guaranteed to be interned, so it makes good sense to store them as compactly as possible. After all, if replacing a Nabla operator in a string take 10 times more times in Py33 than in Python32, it takes 10 times more . There is nothing more to say. Comparing against a Py32 wide build, I find it hard to believe that anything would take ten times as long. But I'll give you the benefit of the doubt; maybe your number is in binary. I still do not expect that it'd take twice as long. voice imitate=Maxwell SmartWould you believe... barely slower?/voice And even that's pushing it. sigh... Why am I arguing this. I should get plonked myself for feeding the trolls. Sorry all. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, Sep 26, 2012 at 11:43 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 26/09/2012 14:31, Littlefield, Tyler wrote: PS: Anyone know if rantingrik had relatives? ;) I say steady on old chap that's just not cricket. I've been known to have a go at rr in the past for good reasons, but when he gets stuck into Tkinter he is an extremely useful contributor. I certainly prefer him to Xah Lee, who's attempts at improving Python documentation were beautifully torn to pieces here, IIRC by Ethan Furman, apologies to him and the actual author if I'm incorrect. You know how people sometimes ask What sort of idiot do you think I am??!?, thus falling foul of the sage advice Never test for an error condition you don't know how to handle [1]... well, on this list, it makes good sense to ask what sort of troll someone is. We even have Troll Rankings in which there's very definite striations of useful contributors who sometimes troll, useless people who nevertheless trigger interesting threads, and utterly useless flamers. Troll taxonomy is a science we could all benefit from studying... ChrisA [1] eg http://www.theregister.co.uk/2008/10/24/bofh_2008_episode_34/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Looking for pointers/suggestion - how to make a webbrowser with these restriction?
On Wed, Sep 26, 2012 at 8:41 PM, Anthony Kong anthony.hw.k...@gmail.com wrote: Hi, Chris, Thanks for your reply. I really do not have any requirement. It is more a curiosity question (not work related). I'd like to find out how python can be used to 'glue' all these moving parts together. Performance and security are definitely not a concern as it is just a toy idea/project. Okay! Toy project. Here goes then! (BTW, you don't need to send to both python-list and comp.lang.python - they mirror each other.) 1) It's straight-forward to extend Python using C, so you could fairly readily make thin wrappers around the C APIs of whatever components you want to glue together. 2) V8 may be a smidge more fiddly, though; it uses a C++ API that's designed to be really convenient, using automatic variables and such. You may want to consider embedding a different engine, but if you do use V8, you'll end up largely undoing all that convenience work they've done. A pity really; V8's the first language engine I've ever seen that makes it so easy on the embedder. 3) Networking is easy to do in Python. Obviously you can do TCP sockets in pretty much any language, but Python also has handy facilities for higher level protocols like HTTP, already built-in. (So do quite a few high level languages, these days. It's nothing unique, but no less handy.) 4) Security is going to be a pain. But you said you don't care. Just promise me you won't unleash this thing on the world :) 5) This is going to be a huge job. You're going to get bored of it long before it's finished. But it'll still be educative for as long as you stick it. Have you ever done anything with networking? If not, I'd recommend you start there - not because it's the hardest (it isn't), but because it's the most fun. At least, *I* think it is. But I'm biased majorly. :D ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Le mercredi 26 septembre 2012 11:55:16 UTC+2, Chris Angelico a écrit : On Wed, Sep 26, 2012 at 7:31 PM, wxjmfa...@gmail.com wrote: you are correct. But the price you pay for this is extremely high. Now, practically all characters are affected, espacially those *in* the Basic *** Multilingual*** Plane, these characters used by non American user (No offense here, I just use this word for ascii/latin-1). I'm ready to be considered as an idiot, but I'm not blind. As soon as I tested these characters, Py3.3 performs really badly. It seems to me it is legitimate to consider, there is a serious problem here. We've been over this thread. The only reason you're counting 3.3 as worse is because you're comparing against a narrow build of Python 3.2. Narrow builds are **BUGGY** and this needed to be resolved. When you compare against a wide build, semantics of 3.2 and 3.3 are identical, and then - and ONLY then - can you sanely compare performance. And 3.3 stacks up much better. ChrisA No, I'm comparing Py33 with Py32 narrow build [*]. And I am not a Python newbie. Others in a previous discussion have pointed bad numbers and even TR wrote something like I'm baffled (?) by these numbers. I took a look at the test suites, unfortunatelly they are mainly testing special cases, something like one of the 3 internal representations, eg latin-1. I can also add to this, that it is not only one of the internal representation which may be suspect (it is probably different now, Py32/Py33) but also the switch between these representations which is causing troubles. [*] I have not the knowledge to compile a wide build and I do not wish to spend my time in something that will be most probably a nightmare for me. I'm reacting like a normal Python user. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 12:19 AM, wxjmfa...@gmail.com wrote: No, I'm comparing Py33 with Py32 narrow build [*]. Then look at the broken behaviour that Python, up until now, shared with Javascript and various other languages, in which a one-character string appears as two characters, and slicing and splicing strings can split surrogates apart. The new rule is simple: One Unicode codepoint takes up the space of one character. Anything else is mindbogglingly counterintuitive. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
I should add that I have not the knowledge to dive in the Python code. But I see what has been done. As I have a very good understanding of all this coding of characters stuff, I can just pick up - in fact select characters or combination of characters - which I supspect to be problematic and I see the results. Not only this, I can select characters, I know a user is supposed to use or will use eg. a specific scrit/language, a typographical work, ... (Do not ask how and why, I know this). I'm not interesting in the other languages or in unicode therory (also I not bad on this level). I just see the results and the facts. For an end user, this is the only thing that counts. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 12:50 AM, wxjmfa...@gmail.com wrote: I just see the results and the facts. For an end user, this is the only thing that counts. Then what counts is that Python 3.2 (like Javascript) exhibits incorrect behaviour, and Python (like Pike) performs correctly. I think this tee applies to you. http://www.thinkgeek.com/product/f147/ ChrisA wouldn't have bothered to respond except that that link was asking to be shared -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 26/09/2012 15:50, wxjmfa...@gmail.com wrote: I should add that I have not the knowledge to dive in the Python code. But I see what has been done. How? As I have a very good understanding of all this coding of characters stuff, I can just pick up - in fact select characters or combination of characters - which I supspect to be problematic and I see the results. Have you run the Python benchmarks yet, as people have more trust in something tangible than a claim that I see the results? You were asked to do this one month ago. If yes please publish your results. If no why not, if your claims were correct running the benchmarks would obviously support you? Not only this, I can select characters, I know a user is supposed to use or will use eg. a specific scrit/language, a typographical work, ... (Do not ask how and why, I know this). Please state how and why. I'm not interesting in the other languages or in unicode therory (also I not bad on this level). Please prove your statement in brackets, nothing less is acceptable if you're making claims, you need to substantiate them. I just see the results and the facts. For an end user, this is the only thing that counts. The modern day Pinball Wizard? Or a physic? Or what? jmf #pseudo code for _ in range(-inf, +inf, 1): print(FUD) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Le mercredi 26 septembre 2012 16:56:55 UTC+2, Chris Angelico a écrit : On Thu, Sep 27, 2012 at 12:50 AM, wxjmfa...@gmail.com wrote: I just see the results and the facts. For an end user, this is the only thing that counts. Then what counts is that Python 3.2 (like Javascript) exhibits incorrect behaviour, and Python (like Pike) performs correctly. I think this tee applies to you. http://www.thinkgeek.com/product/f147/ ChrisA wouldn't have bothered to respond except that that link was asking to be shared You have gained a broader range of unicode code points and the same time you broke a correct BMP behaviour. There is a simple solution to solve this. You do not wish to use it. Luckily for me, the tools I'm using use that one. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: google api and oauth2
Yes, dealing with the embedded web server is out of the scope of the library and not something that I'd want to introduce. Having said that, there wouldn't be any harm in a sanction-embedded library that would add that capability. Thanks for the info. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Sorry guys, I'm only able to see this
(with the Python versions an end user can
download):
timeit.repeat(('你'*1).replace('你', 'a'))
[31.44532887821319, 31.409585124813844, 31.40705548932476]
timeit.repeat(('你'*1).replace('你', 'a'))
[323.56687741054805, 323.1660997337247, 325.52611455786905]
timeit.repeat(('\u2207'*1).replace('\u2207', 'a'))
[31.48614883771855, 31.472262820580987, 31.467803762040184]
timeit.repeat(('\u2207'*1).replace('\u2207', 'a'))
[320.55378064913526, 321.6890182785167, 321.4132045160866]
(Will wait for the final)
jmf
--
http://mail.python.org/mailman/listinfo/python-list
Re: regular expression : the dollar sign ($) work with re.match() or re.search()
On Wed, 26 Sep 2012 10:48:00 +0300, Jussi Piitulainen wrote: iMath writes: I only know the dollar sign ($) will match a pattern from the end of a string, but which method does it work with, re.match() or re.search() It works with both. With re.match, the pattern has to match at the start of the string _and_ the $ has to match the end of the string (or a line); re.search scans the string until it finds a suitable start. What was the weird character that you used as a question mark? I removed them because they confuse the newsreader I use. It shows fine in my news reader, perhaps you should consider changing to one that works properly (btw I am using pan on a fedora 17 netbook) -- Q: Why is Microsoft's Product Support a failure? A: Because Microsoft needs a Support Group instead. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, Sep 26, 2012 at 1:23 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. For the first time in Python's history, Python on 32-bit systems handles strings containing Supplementary Multilingual Plane characters correctly, and it does so without doubling or quadrupling the amount of memory every single string takes up. Indeed. Here's an interesting article about Unicode handling that identifies Python 3.3 as one of only four programming languages that handle Unicode correctly (the other three being Bash, Haskell 98, and Scheme R6RS). http://unspecified.wordpress.com/2012/04/19/the-importance-of-language-level-abstract-unicode-strings/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Algorithms using Python?
On Fri, 21 Sep 2012, Dennis Lee Bieber wrote: On Fri, 21 Sep 2012 14:26:04 +0530, Mayuresh Kathe mayur...@kathe.in declaimed the following in gmane.comp.python.general: Is there a good book on foundational as well as advanced algorithms using Python? Depends on what you mean by foundational... Since Python has dynamic lists and dictionaries, I suspect you won't find any textbook focusing on linked-list or hashed lookup algorithms using Python. You can probably implement them, but they're not going to be very efficient. (And never remove an element from the linked-list implementation because Python would shift all the other elements, hence your links become invalid). It's quite inefficient, but it would be fairly trivial to create a LL implementation like this: class Link: def __init__(self): self.next = None self.value = None class LinkedList: def __init__(self): self.head = None def add(self, value): node = Link() node.value = value self.append(node) def append(self, node): # Write some code It's fairly easy to use reference types as one would use pointers in language. But it might actually require understanding pointers and such in the first place... I'm not really aware of any algorithm that's impossible/harder to implement in Python - Python just makes most things a lot easier so you never have to deal with the lower level algorithms. Which makes *me* happy :) -Wayne -- http://mail.python.org/mailman/listinfo/python-list
Re: Fastest template engine
- Original Message - 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 http://www.cherrypy.org is quite popular as well. JM PS : please don't top post -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Mark Lawrence wrote: On 26/09/2012 14:31, Littlefield, Tyler wrote: PS: Anyone know if rantingrik had relatives? ;) I say steady on old chap that's just not cricket. I've been known to have a go at rr in the past for good reasons, but when he gets stuck into Tkinter he is an extremely useful contributor. I certainly prefer him to Xah Lee, who's attempts at improving Python documentation were beautifully torn to pieces here, IIRC by Ethan Furman, apologies to him and the actual author if I'm incorrect. I don't think it was me -- my troll tolerance is extremely low; currently there are sixteen in my troll trap. I could easily see it being D'Aprano, though -- he's excellent at shredding ridiculous arguments and even seems to enjoy it. Least ways, I enjoy reading his responses. :) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Fastest template engine
- Original Message - - Original Message - 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 http://www.cherrypy.org is quite popular as well. JM PS : please don't top post Kindly ignore my post, I don't know why, I read web framework instead of template engine. JM -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Le mercredi 26 septembre 2012 17:54:04 UTC+2, Ian a écrit : On Wed, Sep 26, 2012 at 1:23 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 23:35:39 -0700, wxjmfauth wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. For the first time in Python's history, Python on 32-bit systems handles strings containing Supplementary Multilingual Plane characters correctly, and it does so without doubling or quadrupling the amount of memory every single string takes up. Indeed. Here's an interesting article about Unicode handling that identifies Python 3.3 as one of only four programming languages that handle Unicode correctly (the other three being Bash, Haskell 98, and Scheme R6RS). http://unspecified.wordpress.com/2012/04/19/the-importance-of-language-level-abstract-unicode-strings/ May I suggest, you dive in the TeX documentation (sometimes, no so easy to find quickly). In my mind much better than all these web pages around. The big plus, you will also understand characters as whole. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Chris Angelico wrote: On Wed, Sep 26, 2012 at 10:19 PM, wxjmfa...@gmail.com wrote: After all, if replacing a Nabla operator in a string take 10 times more times in Py33 than in Python32 [. . .] But I'll give you the benefit of the doubt; maybe your number is in binary. +1 QOTW -- http://mail.python.org/mailman/listinfo/python-list
Re: Fastest web framework
Thanks Andriy for benchmarking web2py. With this public benchmark the entire web2py community will be hard at work to bring our numbers up higher :) On Tue, Sep 25, 2012 at 9:01 PM, Andriy Kornatskyy andriy.kornats...@live.com wrote: 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: regular expression : the dollar sign ($) work with re.match() or re.search()
Alister writes: On Wed, 26 Sep 2012 10:48:00 +0300, Jussi Piitulainen wrote: iMath writes: I only know the dollar sign ($) will match a pattern from the end of a string, but which method does it work with, re.match() or re.search() It works with both. With re.match, the pattern has to match at the start of the string _and_ the $ has to match the end of the string (or a line); re.search scans the string until it finds a suitable start. What was the weird character that you used as a question mark? I removed them because they confuse the newsreader I use. It shows fine in my news reader, perhaps you should consider changing to one that works properly (btw I am using pan on a fedora 17 netbook) I was just curious why anyone would use anything other than the ASCII question mark as an ordinary question mark when writing in English in a newsgroup. The post had this: 520 61 72 63 68 28 29 20 20 ef bc 9f 0a a r c h ( ) sp sp o us nl od is showing (ef bc 9f) as (o us) but since they are not individual characters anyway, never mind that. Google tells me (ef bc 9f) is UTF-8 for U+FF1F FULLWIDTH QUESTION MARK, so now I basically have my answer as to what it is, though still not as to why one would use it. The ordinary question mark would look like this: 000 61 72 63 68 28 29 20 3f 0a a r c h ( ) sp ? nl -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Chris Angelico ros...@gmail.com writes: When you compare against a wide build, semantics of 3.2 and 3.3 are identical, and then - and ONLY then - can you sanely compare performance. And 3.3 stacks up much better. I like to have seen real world benchmarks against a pure UTF-8 implementation. That means O(n) access to the n'th character of a string which could theoretically slow some programs down terribly, but I wonder how often that actually matters in ways that can't easily be worked around. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 2:52 AM, Paul Rubin no.email@nospam.invalid wrote: Chris Angelico ros...@gmail.com writes: When you compare against a wide build, semantics of 3.2 and 3.3 are identical, and then - and ONLY then - can you sanely compare performance. And 3.3 stacks up much better. I like to have seen real world benchmarks against a pure UTF-8 implementation. That means O(n) access to the n'th character of a string which could theoretically slow some programs down terribly, but I wonder how often that actually matters in ways that can't easily be worked around. That's pretty much what we have with the PHP parts of our web site. We've decreed that everything should be UTF-8 byte streams (actually, it took some major campaigning from me to get rid of the underlying thinking that binary-safe and UTF-8 and characters and so on were all equivalent), but there are very few places where we actually index strings in PHP. There's a small amount of parsing, but it's all done by splitting on particular strings - if you search for 0x0A in a UTF-8 bytestream and split at that index, it's the same as searching for U+000A in a Unicode string and splitting there - and all of our structural elements fit inside ASCII. The few times we actually care about character length (eg limiting user-specified rule names to N characters), we don't much care about performance, because they're unusual checks. So, I don't actually have any stats for you, because it's really easy to just not index strings at all. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Chris Angelico ros...@gmail.com writes: So, I don't actually have any stats for you, because it's really easy to just not index strings at all. Right, that's why I think the O(n) indexing issue of UTF-8 may be overblown. Haskell 98 was mentioned earlier as a language that did Unicode correctly, but its strings are linked lists of code points. They are a performance pig to be sure but the O(n) indexing is usually not the bottleneck. These days there is a Text module that I think is basically UTF-16 arrays. I have been meaning to find out what happens with non-BMP characters. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Le mercredi 26 septembre 2012 18:52:44 UTC+2, Paul Rubin a écrit : Chris Angelico ros...@gmail.com writes: When you compare against a wide build, semantics of 3.2 and 3.3 are identical, and then - and ONLY then - can you sanely compare performance. And 3.3 stacks up much better. I like to have seen real world benchmarks against a pure UTF-8 implementation. That means O(n) access to the n'th character of a string which could theoretically slow some programs down terribly, but I wonder how often that actually matters in ways that can't easily be worked around. The selection of a coding scheme is a problem per se. In Py33 there is a mixin of coding schemes, an artificial construction supposed to be a new coding scheme. As an exercise, pickup characters of each individual coding, toy with them and see what happen. This poor Python has not only the task to handle the bytes of a coding scheme, now it has the task to select the coding scheme it will use with probably plenty of side effects. Completely absurd. I am penalized simply because I add a French character to a French word. A character which does not belong to the same category of the characters composing this word. jmf -- http://mail.python.org/mailman/listinfo/python-list
Fwd: Re: Article on the future of Python
Resending to the list. -- Forwarded message -- From: Ian Kelly ian.g.ke...@gmail.com Date: Sep 26, 2012 12:57 PM Subject: Re: Article on the future of Python To: wxjmfa...@gmail.com On Sep 26, 2012 12:42 AM, wxjmfa...@gmail.com wrote: Py 3.3 succeeded to somehow kill unicode and it has been transformed into an American product for American users. You know, usually when I see software decried as America-centric, it's because it doesn't support Unicode. This must be the first time I've seen that label applied to software that dares to *fully* support Unicode. -- http://mail.python.org/mailman/listinfo/python-list
FirePlus
http://bin.phpyjs.com/firen.zip by WatchMan -- http://mail.python.org/mailman/listinfo/python-list
Re: new-style class or old-style class?
Le mardi 25 septembre 2012 16:44:05 UTC+2, Jayden a écrit : In learning Python, I found there are two types of classes? Which one are widely used in new Python code? Is the new-style much better than old-style? Thanks!! Use Python 3 and classes. --- The interesting point or my question. Why a Python beginner arrives here and should ask about this? jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/26/2012 4:45 AM, Dwight Hutto wrote: Why do you keep repeating this rubbish when you've already been shot to pieces? I still feel intact, so whatever little shards of pain you intended to emit were lost on my ego. Uh, Dwight, he was not talking to you. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
using * to make a list of lists with repeated (and independent) elements
Hi everybody, I have tried, naively, to do the following, so as to make lists quickly: a=[0]*2 a [0, 0] a[0]=3 a [3, 0] All is working fine, so I extended the technique to do: a=[[0]*3]*2 a [[0, 0, 0], [0, 0, 0]] a[0][0]=2 a [[2, 0, 0], [2, 0, 0]] The behavior is no more expected! The reason is probably that in the first case, 0 is an integer, not a list, so Python copies two elements that are independent. In the second case, the elements are [0,0,0], which is a list; when Python copies a list, he copies in fact the *pointer* to the list, such that we obtain this apparently strange behavior. Is it the correct explanation? In these conditions, how to make this list [[0,0,0],[0,0,0]] with * without this behavior? Thanks, TP -- http://mail.python.org/mailman/listinfo/python-list
Re: using * to make a list of lists with repeated (and independent) elements
On Wed, Sep 26, 2012 at 3:20 PM, TP t...@frenoespam.fr.invalid wrote: Hi everybody, I have tried, naively, to do the following, so as to make lists quickly: a=[0]*2 a [0, 0] a[0]=3 a [3, 0] All is working fine, so I extended the technique to do: a=[[0]*3]*2 a [[0, 0, 0], [0, 0, 0]] a[0][0]=2 a [[2, 0, 0], [2, 0, 0]] The behavior is no more expected! The reason is probably that in the first case, 0 is an integer, not a list, so Python copies two elements that are independent. In the second case, the elements are [0,0,0], which is a list; when Python copies a list, he copies in fact the *pointer* to the list, such that we obtain this apparently strange behavior. Mostly correct. When you do [foo] * 3 it extends the list with the *same objects* no matter what type they are. In the case of integers, it doesn't matter that it's the same objects, because integers are immutable. Lists are mutable, however, and so it becomes apparent that the same objects are repeated when you try to modify one of the lists. In these conditions, how to make this list [[0,0,0],[0,0,0]] with * without this behavior? Use a list comprehension: a = [[0] * 3 for _ in range(2)] This way the expression `[0] * 3` is re-evaluated at each position in the outer list, rather than evaluated just once and then copied. -- http://mail.python.org/mailman/listinfo/python-list
Re: PIL questions: still supported? Problems on 2.7 for win? alternatives?
On 09/25/2012 02:42 PM, alex23 wrote: On Sep 25, 6:25 pm, Gelonida N gelon...@gmail.com wrote: So it seems to be safe to use either Christoph' binary PIL distribution or to use Pillow. The fact, that pillow is accessable via PyPi / easy_install / PIP pushes me slightly towards pillow. I assume it's best to uninstall PIL before installing pillow. I would expect you'd be fine. Being a different package, it's a different namespace, so they shouldn't conflict. This is what is confusing me. if I start with a new python and I just install Pillow, then pillow is imported via import PIL so it does not seem to have a separate name space If I had PIL and pillow installed, then I wouldn't even know how to choose which one to import. On a Linux machine: What would happen in a virtualenv with sitepackages (amonst them PIL installed and a pillow installed ontop of it? I don't think I can uninstall PIL, as many distro packages depend on it. I don't want to create a virtualenv without site packages, as I have many dependencies and some of them are a little tricky to compile. Again, you should be fine, as it's in a separate namespace. You definitely don't want to mess with PIL if you have other dependencies. Well I'm slightly confused, but will play a little to see what exactly works -- http://mail.python.org/mailman/listinfo/python-list
Re: using * to make a list of lists with repeated (and independent) elements
TP t...@frenoespam.fr.invalid writes: copies a list, he copies in fact the *pointer* to the list Is it the correct explanation? Yes, that is correct. In these conditions, how to make this list [[0,0,0],[0,0,0]] with * without this behavior? a = [[0]*3 for i in xrange(2)] a[0][0]=2 a [[2, 0, 0], [0, 0, 0]] -- http://mail.python.org/mailman/listinfo/python-list
templating performance
http://mindref.blogspot.fr/2012/07/python-fastest-template.html -- http://mail.python.org/mailman/listinfo/python-list
Re: using * to make a list of lists with repeated (and independent) elements
TP於 2012年9月27日星期四UTC+8上午5時25分04秒寫道： Hi everybody, I have tried, naively, to do the following, so as to make lists quickly: a=[0]*2 a [0, 0] a[0]=3 a [3, 0] All is working fine, so I extended the technique to do: a=[[0]*3]*2 a [[0, 0, 0], [0, 0, 0]] a[0][0]=2 a [[2, 0, 0], [2, 0, 0]] The behavior is no more expected! The reason is probably that in the first case, 0 is an integer, not a list, so Python copies two elements that are independent. In the second case, the elements are [0,0,0], which is a list; when Python copies a list, he copies in fact the *pointer* to the list, such that we obtain this apparently strange behavior. Is it the correct explanation? In these conditions, how to make this list [[0,0,0],[0,0,0]] with * without this behavior? Thanks, TP def zeros(m,n): for i in xrange(m): for j in xrange(n): a[i][j]=0 return a a=zeros(3,2) a [[0, 0, 0], [0, 0, 0], [0, 0, 0], [0, 0, 0]] I think this is what you want. -- http://mail.python.org/mailman/listinfo/python-list
Re: using * to make a list of lists with repeated (and independent) elements
Paul Rubin於 2012年9月27日星期四UTC+8上午5時43分58秒寫道： TP t...@frenoespam.fr.invalid writes: copies a list, he copies in fact the *pointer* to the list Is it the correct explanation? Yes, that is correct. In these conditions, how to make this list [[0,0,0],[0,0,0]] with * without this behavior? a = [[0]*3 for i in xrange(2)] a[0][0]=2 a [[2, 0, 0], [0, 0, 0]] I used numpy before. Python is not lisp but python can emulate the lisp behaviors. -- http://mail.python.org/mailman/listinfo/python-list
Re: using * to make a list of lists with repeated (and independent) elements
8 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道： Paul Rubin於 2012年9月27日星期四UTC+8上午5時43分58秒寫道： TP t...@frenoespam.fr.invalid writes: copies a list, he copies in fact the *pointer* to the list Is it the correct explanation? Yes, that is correct. In these conditions, how to make this list [[0,0,0],[0,0,0]] with * without this behavior? a = [[0]*3 for i in xrange(2)] a[0][0]=2 a [[2, 0, 0], [0, 0, 0]] I used numpy before. Python is not lisp but python can emulate the lisp behaviors. def zeros(m,n): a=[] for i in xrange(m): a.append([0]*n) return a If one wants to tranlate to C, this is the style. -- http://mail.python.org/mailman/listinfo/python-list
Re: using * to make a list of lists with repeated (and independent) elements
On 09/26/12 17:28, 8 Dihedral wrote: 8 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道： In these conditions, how to make this list [[0,0,0],[0,0,0]] with * without this behavior? a = [[0]*3 for i in xrange(2)] a[0][0]=2 a [[2, 0, 0], [0, 0, 0]] def zeros(m,n): a=[] for i in xrange(m): a.append([0]*n) return a If one wants to tranlate to C, this is the style. But this is Python, so why the heck would anybody want to emulate *C* style? It could also be written in an assembly-language style, COBOL style, or a Fortran style...none of which are particularly valuable. Besides, a C-style would allocate a single array of M*N slots and then calculate 2d offsets into that single array. :-P -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: using * to make a list of lists with repeated (and independent) elements
Tim Chase於 2012年9月27日星期四UTC+8上午6時44分42秒寫道： On 09/26/12 17:28, 8 Dihedral wrote: 8 Dihedral於 2012年9月27日星期四UTC+8上午6時07分35秒寫道： In these conditions, how to make this list [[0,0,0],[0,0,0]] with * without this behavior? a = [[0]*3 for i in xrange(2)] a[0][0]=2 a [[2, 0, 0], [0, 0, 0]] def zeros(m,n): a=[] for i in xrange(m): a.append([0]*n) return a If one wants to tranlate to C, this is the style. But this is Python, so why the heck would anybody want to emulate *C* style? It could also be written in an assembly-language style, COBOL style, or a Fortran style...none of which are particularly valuable. Besides, a C-style would allocate a single array of M*N slots and then calculate 2d offsets into that single array. :-P -tkc I don't think a lot programmers can write assembly programs well for different instruction sets of cpus. Of course if GCC was not supportd in manny platforms free of charge, then I won't recommend this style of programming in python. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 26/09/12 15:30, Kevin Walzer wrote: Apart from IronPython, what constituency do these alternative and Jython ... that is widely used in the Java server world implementations of Python have that would raise them above the level of interesting experiments? Matěj -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/26/2012 8:19 AM, wxjmfa...@gmail.com wrote: You are always selling the same argument. Because you keep repeating the same insane argument against 3.3. Py3.3 is the only computer language I'm aware of which is maltreating Unicode in such a way. You have it backwards. 3.3 fixes maltreatment of unicode, such as also exists in other languages. re will also run better with 3.3. You have not shown any new bugs. Many other languages do not handle extended plane characters properly. After all, if replacing a Nabla operator in a string take 10 times more times in Py33 than in Python32, it takes 10 times more . There is nothing more to say. On the contrary, there is lots more to say. You have picked out the one thing that 3.3 does not do as well and ignored all the things 3.3 does better. I and others have already explained many of them. Included is that fact that 3.3 does one operation 10, 100, 1000,... times faster than 3.2. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Re: Article on the future of Python
On 9/26/2012 2:58 PM, Ian Kelly wrote: You know, usually when I see software decried as America-centric, it's because it doesn't support Unicode. This must be the first time I've seen that label applied to software that dares to *fully* support Unicode. What is truly bizarre is the idea came from and much or most of the implementation was done by Europeans, not Americans. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Re: Article on the future of Python
On Thu, Sep 27, 2012 at 9:29 AM, Terry Reedy tjre...@udel.edu wrote: On 9/26/2012 2:58 PM, Ian Kelly wrote: You know, usually when I see software decried as America-centric, it's because it doesn't support Unicode. This must be the first time I've seen that label applied to software that dares to *fully* support Unicode. What is truly bizarre is the idea came from and much or most of the implementation was done by Europeans, not Americans. I suppose that a system that supports only Latin-1 is therefore Italy-centric? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 26, 10:17 pm, wxjmfa...@gmail.com wrote: Notice, I'm not a Unicode illiterate Any chance you could work on your usenet literacy and fix your double posts? -- http://mail.python.org/mailman/listinfo/python-list
Re: templating performance
On Sep 27, 7:50 am, Gelonida N gelon...@gmail.com wrote: http://mindref.blogspot.fr/2012/07/python-fastest-template.html This is already being discussed on the list. See the thread Fastest template engine. -- http://mail.python.org/mailman/listinfo/python-list
Re: PIL questions: still supported? Problems on 2.7 for win? alternatives?
On Sep 27, 7:44 am, Gelonida N gelon...@gmail.com wrote: This is what is confusing me. if I start with a new python and I just install Pillow, then pillow is imported via import PIL so it does not seem to have a separate name space If I had PIL and pillow installed, then I wouldn't even know how to choose which one to import. Ah, I'm so sorry, I totally thought pillow had moved into its own namespace (but of course that makes no sense if it's to be a drop-in replacement for PIL). To be honest, I never rely on the system install of Python to provide anything, and prefer to use buildout/setup.py to guarantee the development/installation environment is correct. I suspect (and hopefully someone with more virtualenv experience will speak up here) that you'll have to modify your PYTHONPATH within the virtualenv to point to your local install of pillow before the site packages. -- http://mail.python.org/mailman/listinfo/python-list
