Re: Article on the future of Python
in 681910 20120927 131113 Devin Jeanpierre jeanpierr...@gmail.com wrote: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: Sure, you have all these legitimate concerns, but look, cake! Quote : This piece argues that Python is an easy-to-learn language that where you can be almost immediately productive in. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Summary of that article: Sure, you have all these legitimate concerns, but look, cake! Quote : This piece argues that Python is an easy-to-learn language that where you can be almost immediately productive in. It is, but so is every other language. hello world is the standard... follow the syntax, import/include the appropriate library functions, and create your own to use them. -- 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 27/09/2012 20:08, Terry Reedy wrote: On 9/27/2012 5:33 AM, Steven D'Aprano wrote: Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not. If anyone else can confirm similar results, I already did, about a month ago, for windows. I think the actual problem is with find, not replace (which does a find before the replace). When I asked on pydev, Victor Stinner had no explanation, but said he might look into it eventually. Others thought it not terribly important since 7 times blazingly fast is still fast (in your example, 29 versus 3 microseconds per operation. jmf wrapping a possible real issue with anti-3.3 crud did not help in getting attention to the regression. I also reported results of running stringbench.py on both 3.2 and 3.3 on windows. Overall, Unicode is nearly as fast as bytes and 3.3 as fast as 3.2. Find/replace is the notable exception in stringbench, so it is an anomaly. Other things are faster in 3.3. I think this should be raised as a performance regression. I agree, and Mark did it. http://bugs.python.org/issue16061 and you should read it. I've tried to really muddy the waters by opening this issue, and the python devs are giving out facts, how dare they!!! It's just not my day is it? :( -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 27, 5:11 pm, Devin Jeanpierre jeanpierr...@gmail.com wrote: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: Sure, you have all these legitimate concerns, but look, cake! -- Devin My summary of the first (worried about python) article: Python is about to miss the Bell's law bus: http://en.wikipedia.org/wiki/Bell%27s_Law_of_Computer_Classes -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, 28 Sep 2012 05:08:24 -0700, rusi wrote: On Sep 27, 5:11 pm, Devin Jeanpierre jeanpierr...@gmail.com wrote: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: Sure, you have all these legitimate concerns, but look, cake! -- Devin My summary of the first (worried about python) article: Python is about to miss the Bell's law bus: http://en.wikipedia.org/wiki/Bell%27s_Law_of_Computer_Classes Except that very concept is stupid. Mainframes have not be replaced. There are more mainframes around today than fifty years ago. Minicomputers too, only we don't call them minicomputers, we call them servers. In ten years time, there will be more desktop PCs around than now. Most of them will be in the 90% of the world that isn't America. And most of them will be laptops. But they'll be used as desktops too. Not everybody wants to read email on a device smaller than your hand, clumsily poking at a tiny virtual keyboard. And anybody who thinks that Python can't run on tablets or smartphones hasn't been paying attention. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 28, 5:54 pm, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Fri, 28 Sep 2012 05:08:24 -0700, rusi wrote: On Sep 27, 5:11 pm, Devin Jeanpierre jeanpierr...@gmail.com wrote: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: Sure, you have all these legitimate concerns, but look, cake! -- Devin My summary of the first (worried about python) article: Python is about to miss the Bell's law bus: http://en.wikipedia.org/wiki/Bell%27s_Law_of_Computer_Classes Except that very concept is stupid. Mainframes have not be replaced. There are more mainframes around today than fifty years ago. Minicomputers too, only we don't call them minicomputers, we call them servers. In ten years time, there will be more desktop PCs around than now. Most of them will be in the 90% of the world that isn't America. And most of them will be laptops. But they'll be used as desktops too. Not everybody wants to read email on a device smaller than your hand, clumsily poking at a tiny virtual keyboard. And anybody who thinks that Python can't run on tablets or smartphones hasn't been paying attention. -- Steven It would be good to pay attention before calling others to pay attention. http://litmus.com/blog/email-client-market-share-stats-infographic-june-2012/email-client-market-share-june-2012 -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sat, Sep 29, 2012 at 12:31 AM, Dennis Lee Bieber wlfr...@ix.netcom.com wrote: On Fri, 28 Sep 2012 14:37:21 +1000, Chris Angelico ros...@gmail.com declaimed the following in gmane.comp.python.general: For further details, poke around on the web; I'm sure you'll find plenty of good blog posts etc. But as for me and my house, we will have Postgres serve us. Please, at least use the proper name... Postgres is a non-SQL database inspired by Ingres. PostgreSQL is Postgres with an SQL query engine. http://www.postgresql.org/docs/9.1/static/history.html Many people continue to refer to PostgreSQL as Postgres (now rarely in all capital letters) because of tradition or because it is easier to pronounce. This usage is widely accepted as a nickname or alias. There's lots of internal documentation that references Postgres. I don't see it as that big a deal. On my side... I have MySQL running on my desktop. When I started, MySQL had a native build that would run on Win9X; PostgreSQL at the time required installing a Cygwin environment. MySQL v5 has improved a lot from those days (v3)... It now supports stored procedures, triggers, a form of views, and prepared statements (though MySQLdb is still pre v5 and sends completely formatted string queries). They've even added GIS capabilities. (And then there is the drop-in replacement for MySQL -- MariaDB: http://kb.askmonty.org/en/mariadb-vs-mysql-compatibility/ ) Yes, MySQL has definitely improved. There was a time when its unreliability applied to all your data too, but now you can just click in InnoDB and have mostly-real transaction support etc. But there's still a lot of work that by requirement happens outside of transactions - MySQL doesn't let you roll back DDL, for instance. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, Sep 28, 2012 at 8:58 AM, Chris Angelico ros...@gmail.com wrote: Yes, MySQL has definitely improved. There was a time when its unreliability applied to all your data too, but now you can just click in InnoDB and have mostly-real transaction support etc. But there's still a lot of work that by requirement happens outside of transactions - MySQL doesn't let you roll back DDL, for instance. Neither does Oracle, for that matter. I don't really see any reason why DDL *should* be transactional in nature. If your web app is issuing DDL statements, then you're probably doing something wrong. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sat, Sep 29, 2012 at 1:14 AM, Ian Kelly ian.g.ke...@gmail.com wrote: On Fri, Sep 28, 2012 at 8:58 AM, Chris Angelico ros...@gmail.com wrote: Yes, MySQL has definitely improved. There was a time when its unreliability applied to all your data too, but now you can just click in InnoDB and have mostly-real transaction support etc. But there's still a lot of work that by requirement happens outside of transactions - MySQL doesn't let you roll back DDL, for instance. Neither does Oracle, for that matter. I don't really see any reason why DDL *should* be transactional in nature. If your web app is issuing DDL statements, then you're probably doing something wrong. I have an auto-update script that ensures that our database is at the correct patchlevel. It's fairly straight-forward: switch on patchlevel, execute the statements required to get up to the next one, at the bottom record the patchlevel in the database. (This relieves us of issues of schema changes done in development that didn't get pushed to production, for instance; our source code repository has _everything_ needed.) If anything goes wrong, Postgres will roll the transaction back. It doesn't matter if the first statement added a column to a table and the second does an INSERT... SELECT; they both get rolled back (as would any change to the patchlevel field, though that happens at the very end so it's not significant here). I can guarantee that the patch has either been completely applied or completely rolled back - exactly what transactions are for. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 09/27/2012 10:37 PM, Chris Angelico wrote:[...] * MySQL is designed for dynamic web sites, with lots of reading and not too much writing. Its row and table locking system is pretty rudimentary, and it's quite easy for performance to suffer really badly if you don't think about it. But if your needs are simple, MySQL is probably enough. PostgreSQL uses MVCC to avoid locks in many cases. You can happily read from a row while it's being updated; you'll be unaware of the update until it's committed. MVCC comes with a cost though, as anyone who has ever needed to do a SELECT COUNT(*) on a large Postgresql table knows. [...] * Both engines have good support in popular languages, including (dragging this back on topic, kicking and screaming) Python. Maybe things are different now but a few years ago I was trying to choose between Postgresql and Mysql about the time Python 2.4 (I think) was released. After waiting for over a year for the Python mysql dbi module to be released for the then current version of Python (I needed a binary for Windows) I finally gave up and decided to go with Postgresql (the psycopg2 module was available a very short time after the new Python was.) -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 8:59 PM, alex23 wuwe...@gmail.com wrote: On Sep 28, 2:17 am, Devin Jeanpierre jeanpierr...@gmail.com wrote: Uncharitably, it's just a way of hiding one's head in the sand, ignoring any problems Python has by focusing on what problems it doesn't have. But isn't that what counterpoint is all about? Actually I think it's about the charitable interpretation. Nobody writes an article and says, I'm going to stick my head in the sand. I do believe the article is trying to provide a counterweight to the gloomy mood set by the first. Calvin's article highlighted what he felt were areas that Python isn't successful, while Tim McNamara's pointed out areas it was. Just because Python isn't used much in commercial video games doesn't undermine the point that it's heavily used in education and research. Absolutely. But also, vice versa -- just because Python is a wonderful language for education and research does not mean that its problems in commercial video games are not worth looking at. Does Python _have_ to be a go-to tool in gaming for it to not be on its death march? I don't think anyone is arguing it's on a death march, just that there are issues that we downplay but should address to keep a vibrant and diverse community. Or something. I'm pretty sure nobody thinks Python is on a death march. Or more to the point: rather than just complain about it... It's not like there aren't active communities that _are_ working in this area: PyGame, pyglet, Kivy are all projects that can be contributed to. Haha, I wouldn't phrase it as complaining. Of these, I have mixed feelings. For example, Calvin has concerns that Python isn't so good on mobile because battery usage (or some such thing). I have no experience on mobile development, so no comment there. I intend to use Kivy this weekend actually, so... Maybe this one is very promising! You didn't mention it, but for the browser issue there is PyJS... but we've all heard the issues that project has. Not sure if there are sane alternatives. Perhaps Silverlight? In all cases you end up with output that's rather large. I'm not sure how practical it is, in the end, to use Python. It may just be that the difference in productivity for common web tasks, is tiny enough that the difficulty of setting up an efficient python-JS toolchain is overwhelming. As for pygame and pyglet, and game development, well, those are things. That's a sort of frustrating response for a number of reasons, but I'll keep it to just one: Those have been around for a very long time, and are very stable (to the point where the infrequency of updates sometimes leads to questions as to whether they're even maintained (I think they are)). The situation for using Python for game development is virtually unchanged in the past several years, and it's been failing for the past several years, so these two projects can't fix it. If these are the best we have, barring additional argument we are going nowhere on this front. For what it's worth, I think there are much larger problems in the game development world than how well Python is faring. Open source projects for game development are few and of not-so-amazing quality. I love using Python and will endeavour to do so wherever I can, but it's always going to be the case that a language has strengths weaknesses that other languages lack. Absolutely! Python will never be perfect. There will always be paths we can take to improve it. And we should always seek to improve it, as long as we stand behind it as a good and useful language compared to the alternatives. On the other hand, I will not use Python wherever I can. I will use it wherever it makes the most sense to use it. For example, I would write a first person shooter game in C# and Unity 3D, and I would write my AJAX website in Javascript. It's just easier for me that way. Why use Python if it makes my job harder? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, 28 Sep 2012 14:50:14 -0400, Devin Jeanpierre wrote: I'm pretty sure nobody thinks Python is on a death march. Don't be so sure. There's always *someone* complaining about something, and they're usually convinced that (Language X) is on it's last legs because (feature Y) is missing or (event Z) happened. Seriously. If you believe the haters and the complainers, Python will never be taken seriously as a language because: - it has significant whitespace. - it doesn't have braces. - it doesn't have static typing. - Python is too slow. - it has lost momentum to Ruby on RAILS. - it has lost momentum to Javascript. - it doesn't have a real garbage collector that can collect cycles. - oh, Python has had one of those for a decade? I meant a garbage collector that can collect cycles involving objects with __del__ methods. - threads aren't exactly like threads in some other language. - Python only uses a single core of the CPU. - I mean CPython. IronPython and Jython don't count. - I mean ordinary Python code, using multiprocessing doesn't count. - Neither do C extensions or numpy. - Python changes too fast. People can't keep up. Python should be an ISO standard managed by a committee, like C, with a guarantee that 30 year old code will run in the latest version. - Python changes too slow. People can't use all these great new features. It has gotten too big and the developers care too much about backward compatibility and aren't willing to delete cruft from the language. - you can't compile to native machine code. No language can possibly be successful with byte-code running in a virtual machine. - it isn't a pure object-oriented language exactly like Java. - you can't hide your source code from the end user. People will STEEEAL MY INTELLECTUUUALL PROPERTY!!! - oh, you can? Yeah, but it's too hard, and besides they might decompile the .pyc files. - Python 3 is a failure and has split the community. I think I've got all the most common reasons for dismissing Python. Python has lost ground to Flash is a new one for me, as is Python ate my mobile phone's batteries. In a way, it's quite unfortunate that you can't write a blog post discussing weaknesses of a language (as opposed to strengths) without turning it into fuel for the haters: http://news.ycombinator.com/item?id=4567023 But when you give a blog post an inflammatory title like I am worried about the future of Python, what do you expect? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, 27 Sep 2012 15:37:35 +1000, Chris Angelico wrote: On Thu, Sep 27, 2012 at 10:44 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: While PyPy is still a work in progress, and is not anywhere near as mature as (say) gcc or clang, it should be considered production-ready. That's all very well, but unless I have my facts badly wrong, PyPy is only compatible with Python 2 - right? At the moment, yes. Support for Python 3 is in active development. http://morepypy.blogspot.com/2012/09/py3k-status-update-6.html [...] Assuming it manages to catch up with Py3, which a decade makes entirely possible, this I can well believe. And while we're sounding all hopeful, maybe Python will be on popularity par with every other P in the classic LAMP stack. *That* would be a Good Thing. Given how Perl has slipped in the last decade or so, that would be a step backwards for Python :-P -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 27 Sep 2012 15:37:35 +1000, Chris Angelico wrote: Assuming it manages to catch up with Py3, which a decade makes entirely possible, this I can well believe. And while we're sounding all hopeful, maybe Python will be on popularity par with every other P in the classic LAMP stack. *That* would be a Good Thing. Given how Perl has slipped in the last decade or so, that would be a step backwards for Python :-P LAMP usually means PHP these days. There's a lot of that around. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Tue, 25 Sep 2012 09:15:00 +0100, 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 And a response: http://data.geek.nz/python-is-doing-just-fine -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27.09.12 09:08, Chris Angelico wrote: LAMP usually means PHP these days. There's a lot of that around. And Cyrillic Р means Ruby. :-P -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, 26 Sep 2012 08:45:30 -0700, wxjmfauth wrote:
Sorry guys, I'm only able to see this (with the Python versions an end
user can download):
[snip timeit results]
While you have been all doom and gloom and negativity that Python has
destroyed Unicode, I've actually done some testing. It seems that,
possibly, there is a performance regression in the replace method.
This is on Debian squeeze, using the latest rc version of 3.3, 3.3.0rc3:
py timeit.repeat(('b'*1000).replace('b', 'a'))
[28.308280900120735, 29.012173799797893, 28.834429003298283]
Notice that Unicode doesn't come into it, they are pure ASCII strings.
Here's the same thing using 3.2.2:
py timeit.repeat(('b'*1000).replace('b', 'a'))
[3.618225097656, 3.147739887237549, 3.132185935974121]
That's a factor of 9 slowdown in 3.3, and no Unicode. Obviously Python
has destroyed ASCII.
(I get similar slowdowns for Unicode strings too, so clearly Python hates
all strings, not just ASCII.)
Now, for irrelevant reasons, here I swapped to Centos.
[steve@ando ~]$ python2.7 -m timeit 'b'*1000
100 loops, best of 3: 0.48 usec per loop
[steve@ando ~]$ python3.2 -m timeit 'b'*1000
100 loops, best of 3: 1.3 usec per loop
[steve@ando ~]$ python3.3 -m timeit 'b'*1000
100 loops, best of 3: 0.397 usec per loop
Clearly 3.3 is the fastest at string multiplication, at least for this
trivial example. Just to prove that the result also applies to Unicode:
[steve@ando ~]$ python3.3 -m timeit ('你'*1000)
100 loops, best of 3: 1.38 usec per loop
Almost identical to 3.2. And the reason it is slower than the 3.3 test
using 'b' above is almost certainly because the string uses four times
more memory:
[steve@ando ~]$ python3.3 -m timeit ('abcd'*1000)
100 loops, best of 3: 0.919 usec per loop
So a little slower that the pure-ASCII version for the same amount of
memory, but not significantly so.
But add a call to replace, and things are very different:
[steve@ando ~]$ python2.7 -m timeit -s s = 'b'*1000 s.replace('b', 'a')
10 loops, best of 3: 9.3 usec per loop
[steve@ando ~]$ python3.2 -m timeit -s s = 'b'*1000 s.replace('b', 'a')
10 loops, best of 3: 5.43 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s s = 'b'*1000 s.replace('b', 'a')
10 loops, best of 3: 18.3 usec per loop
Three times slower, even for pure-ASCII strings. I get comparable results
for Unicode. Notice how slow Python 2.7 is:
[steve@ando ~]$ python2.7 -m timeit -s s = u'你'*1000 s.replace(u'你', u'a')
1 loops, best of 3: 65.6 usec per loop
[steve@ando ~]$ python3.2 -m timeit -s s = '你'*1000 s.replace('你', 'a')
10 loops, best of 3: 2.79 usec per loop
[steve@ando ~]$ python3.3 -m timeit -s s = '你'*1000 s.replace('你', 'a')
1 loops, best of 3: 23.7 usec per loop
Even with the performance regression, it is still over twice as fast as
Python 2.7.
Nevertheless, I think there is something here. The consequences are nowhere
near as dramatic as jmf claims, but it does seem that replace() has taken a
serious performance hit. Perhaps it is unavoidable, but perhaps not.
If anyone else can confirm similar results, I think this should be raised as
a performance regression.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Hi Sorry guys, I'm only able to see this (with the Python versions an end user can download): [snip timeit results] While you have been all doom and gloom and negativity that Python has destroyed Unicode, I thought that jmf's concerns were solely concerned with the selection of latin1 as the 1 byte set. My impression was that if some set of characters was chosen that included all characters commonly used in French then all would be well with the world. But now I'm confused because latin1 seems to cater for French quite well: http://en.wikipedia.org/wiki/ISO/IEC_8859-1 -- Regards Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: Sure, you have all these legitimate concerns, but look, cake! -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27.09.12 12:33, Steven D'Aprano wrote: Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not. If anyone else can confirm similar results, I think this should be raised as a performance regression. Yes, I confirm, it's a performance regression. It should be avoidable. Almost any PEP393 performance regression can be avoided. At least for such corner case. Just no one has yet optimized this case. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 2012-09-27, Chris Angelico ros...@gmail.com wrote: On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Given how Perl has slipped in the last decade or so, that would be a step backwards for Python :-P LAMP usually means PHP these days. There's a lot of that around. Yea, unfortunately. What a mess of a language. I recently had to learn enough PHP to make some changes to a web site we had done by an outside contractor. PHP feels like it was designed by taking a half-dozen other languages, chopping them into bits and then pulling random features/syntax/semantics at random from the various different piles. Those bits where then stuck together with duct tape and bubble gum and called PHP... As one of the contractors who wrote some of the PHP said: PHP is like the worst parts of shell, Perl, and Java all combined into one language! -- Grant Edwards grant.b.edwardsYow! Did something bad at happen or am I in a gmail.comdrive-in movie?? -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: Sure, you have all these legitimate concerns, but look, cake! Did you read the article or just make up a witty response? If so, you half succeeded. It's more like, Well, maybe, your concerns *might* be legitimate, but I don't think so because... and then he gives half a dozen or more reasons why Python is in no danger. None of which involve cake, although one of them did involve Raspberry Pi. An easy mistake to make. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 11:59 PM, Grant Edwards invalid@invalid.invalid wrote: On 2012-09-27, Chris Angelico ros...@gmail.com wrote: On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Given how Perl has slipped in the last decade or so, that would be a step backwards for Python :-P LAMP usually means PHP these days. There's a lot of that around. Yea, unfortunately. What a mess of a language. I recently had to learn enough PHP to make some changes to a web site we had done by an outside contractor. PHP feels like it was designed by taking a half-dozen other languages, chopping them into bits and then pulling random features/syntax/semantics at random from the various different piles. Those bits where then stuck together with duct tape and bubble gum and called PHP... As one of the contractors who wrote some of the PHP said: PHP is like the worst parts of shell, Perl, and Java all combined into one language! I can't remember where I read it, and I definitely don't know if it's accurate to current thinking, but the other day I found a quote purporting to be from the creator of PHP saying that he didn't care about memory leaks, just restart Apache periodically. It's definitely true of most PHP scripts that they're unconcerned about resource leakage, on the assumption that everything'll get cleared out at the end of a page render. PHP seems to encourage sloppiness. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 4:43 AM, Alex Strickland s...@mweb.co.za wrote: I thought that jmf's concerns were solely concerned with the selection of latin1 as the 1 byte set. My impression was that if some set of characters was chosen that included all characters commonly used in French then all would be well with the world. But now I'm confused because latin1 seems to cater for French quite well: http://en.wikipedia.org/wiki/ISO/IEC_8859-1 I understand ISO 8859-15 (Latin-9) to be the preferred Latin character set for French, as it includes the Euro sign as well as a few characters that are not in Latin-1 but are nonetheless infrequently found in French. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 13:46, Serhiy Storchaka wrote: On 27.09.12 12:33, Steven D'Aprano wrote: Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not. If anyone else can confirm similar results, I think this should be raised as a performance regression. Yes, I confirm, it's a performance regression. It should be avoidable. Almost any PEP393 performance regression can be avoided. At least for such corner case. Just no one has yet optimized this case. I have taken a liberty and raised this on the bug tracker quoting Steven D'Aprano's original figures and your response above. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: Sure, you have all these legitimate concerns, but look, cake! Did you read the article or just make up a witty response? If so, you half succeeded. It's more like, Well, maybe, your concerns *might* be legitimate, but I don't think so because... and then he gives half a dozen or more reasons why Python is in no danger. None of which involve cake, although one of them did involve Raspberry Pi. An easy mistake to make. Haha! :) Well, I don't agree. But let me explain. If we're going to have a serious discussion about the problems Python faces in the future, then the topics that Calvin brings up are relevant. These are problems that, ideally, we would overcome. And I think, to some degree, we are working towards a future where these problems are solved. (Except perhaps the game development one, which is a rather tough problem in a lot of ways.) As people have noted, we do have Kivy, we do have PyPy, we do have PyJS and other such things. The future has possibilities for the problems Calvin mentions to be solved, even if they are problems today. The article that was linked, the response, it doesn't talk about this. When Calvin says that Python has problems with mobile, the article doesn't even say but Kivy does mobile -- it says but Science people love Python! When Calvin says that Python has problems being done on the web, the article doesn't even say but PyJS! (regardless of the problems of relying on a hijacked project), it says education loves Python! When Calvin says that Python has failed for game development, the article doesn't try to explain any way that Python is moving to success here, or any way that Calvin's assessment is wrong. Instead, it says, But The Web loves Python! There is a pattern here. The pattern is that the article does not actually directly respond to anything Calvin said. It doesn't try to carry a dialogue about concerns about problem areas Python has. It ignores Python's problems, and focuses on its strengths. Charitably, maybe we'd call this a way of encouraging people who are discouraged by the bleaker tone of Calvin's post. And that's valid, if we're worried about morale. Definitely Calvin's post could be -- and has been -- taken the wrong way. It could be taken as a way of saying, Python is doomed!, even though that isn't something Calvin ever wrote (he appears, from my reading, to be more worried about a stagnating community than a failed language). Under that interpretation, we would want other, more encouraging voices around, talking about ways in which Python is good and will survive. Uncharitably, it's just a way of hiding one's head in the sand, ignoring any problems Python has by focusing on what problems it doesn't have. So that's why I said that the summary is, but look, cake!. Instead of being a dialogue about improving Python, it's a distraction from the issues Calvin brought up. It brings up strengths, which are also part of Python, but don't have much at all to do with Python's weaknesses, or with what Calvin was talking about. -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 17:16, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Tue, 25 Sep 2012 09:15:00 +0100, Mark Lawrence wrote: And a response: http://data.geek.nz/python-is-doing-just-fine Summary of that article: Sure, you have all these legitimate concerns, but look, cake! Did you read the article or just make up a witty response? If so, you half succeeded. It's more like, Well, maybe, your concerns *might* be legitimate, but I don't think so because... and then he gives half a dozen or more reasons why Python is in no danger. None of which involve cake, although one of them did involve Raspberry Pi. An easy mistake to make. Haha! :) Well, I don't agree. But let me explain. [snipped] -- Devin The article Steven D'Aprano referred to is not a direct response to the article I referred to, yet your words are written as if it were. May I ask why? Or have I missed something? -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 07:13, Steven D'Aprano wrote: On Tue, 25 Sep 2012 09:15:00 +0100, 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 And a response: http://data.geek.nz/python-is-doing-just-fine Well there's definite proof that the PyPy people are all completely incompetent in a response on the above link, this is how easy it is But ... why does the runtime environment have to be so limiting? Operations involving primitives could be easily compiled (on the fly - JIT) to machine code and more advanced objects exist as plug-ins. Oh, and it would be nice to be able to write such objects quickly and easily - not the convoluted mess that it is currently. Simples :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, Sep 28, 2012 at 2:45 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: The article Steven D'Aprano referred to is not a direct response to the article I referred to, yet your words are written as if it were. May I ask why? Or have I missed something? Steven cited it with the words And a response. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 12:45 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: The article Steven D'Aprano referred to is not a direct response to the article I referred to, yet your words are written as if it were. May I ask why? Or have I missed something? Post hoc ergo propter hoc :( -- Devin -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 17:49, Chris Angelico wrote: On Fri, Sep 28, 2012 at 2:45 AM, Mark Lawrence breamore...@yahoo.co.uk wrote: The article Steven D'Aprano referred to is not a direct response to the article I referred to, yet your words are written as if it were. May I ask why? Or have I missed something? Steven cited it with the words And a response. ChrisA Fair enough, we'll blame Steven on the grounds that he's Antipodean :) -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Mark Lawrence wrote: On 27/09/2012 17:16, Devin Jeanpierre wrote: On Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano wrote: On Thu, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: Summary of that article: Sure, you have all these legitimate concerns, but look, cake! Did you read the article or just make up a witty response? If so, you half succeeded. It's more like, Well, maybe, your concerns *might* be legitimate, but I don't think so because... and then he gives half a dozen or more reasons why Python is in no danger. None of which involve cake, although one of them did involve Raspberry Pi. An easy mistake to make. Haha! :) Well, I don't agree. But let me explain. [snipped] The article Steven D'Aprano referred to is not a direct response to the article I referred to, yet your words are written as if it were. May I ask why? Or have I missed something? The second article didn't reference the first directly, but was aimed at that general type of article. At any rate, Steven wrote as if it were a direct response. ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27.09.12 18:06, Ian Kelly wrote:
I understand ISO 8859-15 (Latin-9) to be the preferred Latin character
set for French, as it includes the Euro sign as well as a few
characters that are not in Latin-1 but are nonetheless infrequently
found in French.
Even for Latin-9 Python 3.3 can be a little faster 3.2.
$ ./python -m timeit -s s=bytes(range(256))*100 s.decode('latin1')
Python 2.7: 105 usec
Python 3.2: 20.4 usec
Python 3.3: 4.98 usec
$ ./python -m timeit -s s=bytes(range(256))*100 s.decode('latin9')
Python 2.7: 700 usec
Python 3.2: 94.6 usec
Python 3.3: 93.2 usec
--
http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 5:33 AM, Steven D'Aprano wrote: Nevertheless, I think there is something here. The consequences are nowhere near as dramatic as jmf claims, but it does seem that replace() has taken a serious performance hit. Perhaps it is unavoidable, but perhaps not. If anyone else can confirm similar results, I already did, about a month ago, for windows. I think the actual problem is with find, not replace (which does a find before the replace). When I asked on pydev, Victor Stinner had no explanation, but said he might look into it eventually. Others thought it not terribly important since 7 times blazingly fast is still fast (in your example, 29 versus 3 microseconds per operation. jmf wrapping a possible real issue with anti-3.3 crud did not help in getting attention to the regression. I also reported results of running stringbench.py on both 3.2 and 3.3 on windows. Overall, Unicode is nearly as fast as bytes and 3.3 as fast as 3.2. Find/replace is the notable exception in stringbench, so it is an anomaly. Other things are faster in 3.3. I think this should be raised as a performance regression. I agree, and Mark did it. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
This flexible string representation is wrong by design. Expecting to divide Unicode in chunks and to gain something is an illusion. It has been created by a computer scientist who thinks bytes when on that field one has to think bytes and usage of the characters at the same time. The latin-1 chunk illustrates this wonderfully. jmf -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 12:16 PM, Devin Jeanpierre wrote: Charitably, maybe we'd call this a way of encouraging people who are discouraged by the bleaker tone of Calvin's post. And that's valid, if we're worried about morale. Definitely Calvin's post could be -- and has been -- taken the wrong way. It could be taken as a way of saying, Python is doomed!, even though that isn't something Calvin ever wrote (he appears, from my reading, to be more worried about a stagnating community than a failed language). The title was i-am-worried-about-the-future-of-python (as in 'I am afraid Python will not have one'), not 'python has problems in some application areas'. Given the doom-y title and the tone of the article, excuse me for thinking doom was the topic. As for community: Calvin is worried that all the hot new people in these particular areas will not use and contribute to Python and the community. Under that interpretation, we would want other, more encouraging voices around, talking about ways in which Python is good and will survive. And that is what the second article was about. It turns out that there are hot new people in other growing areas where Python is growing. Computing for science, megadata, and education are not going away. Being a glue language for numerical computing was Python's first killer application nearly two decades ago, and it still is an important one. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 20:09, wxjmfa...@gmail.com wrote: This flexible string representation is wrong by design. Please state who agrees with this and why. Expecting to divide Unicode in chunks and to gain something is an illusion. Please provide the benchmarks to support your claim. It has been created by a computer scientist who thinks bytes when on that field one has to think bytes and usage of the characters at the same time. Please name this computer scientist so everybody knows to whom you are referring. The latin-1 chunk illustrates this wonderfully. I understand from an earlier post that latin-9 meets your needs completely for all French language characters plus the Euro sign, why don't you simply use that and stop rabitting on about latin-1. jmf Would you please be so kind as to stand up as your voice is rather muffled. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
You're posting to both comp.lang.python and python-list, are you aware that that's redundant? On Fri, Sep 28, 2012 at 5:09 AM, wxjmfa...@gmail.com wrote: This flexible string representation is wrong by design. Expecting to divide Unicode in chunks and to gain something is an illusion. It has been created by a computer scientist who thinks bytes when on that field one has to think bytes and usage of the characters at the same time. There's another range of numbers that, in some languages, is divided for efficiency's sake: Integers below 1[bit size]. In Python 2, such numbers were an entirely different data type (int vs long); other languages let you use the same data type for both, but (15)+1 will be executed much faster than (1500)+1. (And far as I know, a conforming Python 3 implementation should be allowed to do that; 3.2 on Windows doesn't seem to, though.) That's all PEP 393 is; it's a performance improvement for a particular subset of values that happens to fit conveniently into the underlying machine's data storage. If Python were implemented on a 9-bit computer, I wouldn't be surprised if the PEP 393 optimizations were applied differently. It's nothing to do with Latin-1, except insofar as the narrowest form of string _happens_ to contain everything that's in Latin-1. Go blame the Unicode consortium for picking that. The latin-1 chunk illustrates this wonderfully. Aside from replace(), as mentioned in this thread, are there any other ways that this is so wonderfully illustrated? Or is it wonderfully as in I wonder if people will believe me if I keep spouting unsubstantiated claims? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 28, 2:47 am, Mark Lawrence breamore...@yahoo.co.uk wrote: ... why does the runtime environment have to be so limiting? Operations involving primitives could be easily compiled (on the fly - JIT) to machine code and more advanced objects exist as plug-ins. Oh, and it would be nice to be able to write such objects quickly and easily - not the convoluted mess that it is currently. Simples :) You should see how awesome _my_ imaginary implementation is! -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 28, 2:17 am, Devin Jeanpierre jeanpierr...@gmail.com wrote: Uncharitably, it's just a way of hiding one's head in the sand, ignoring any problems Python has by focusing on what problems it doesn't have. But isn't that what counterpoint is all about? Calvin's article highlighted what he felt were areas that Python isn't successful, while Tim McNamara's pointed out areas it was. Just because Python isn't used much in commercial video games doesn't undermine the point that it's heavily used in education and research. Does Python _have_ to be a go-to tool in gaming for it to not be on its death march? Or more to the point: rather than just complain about it... It's not like there aren't active communities that _are_ working in this area: PyGame, pyglet, Kivy are all projects that can be contributed to. I love using Python and will endeavour to do so wherever I can, but it's always going to be the case that a language has strengths weaknesses that other languages lack. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, 28 Sep 2012 00:32:58 +1000, Chris Angelico wrote: On Thu, Sep 27, 2012 at 11:59 PM, Grant Edwards invalid@invalid.invalid wrote: On 2012-09-27, Chris Angelico ros...@gmail.com wrote: On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Given how Perl has slipped in the last decade or so, that would be a step backwards for Python :-P LAMP usually means PHP these days. There's a lot of that around. Yea, unfortunately. What a mess of a language. I recently had to learn enough PHP to make some changes to a web site we had done by an outside contractor. PHP feels like it was designed by taking a half-dozen other languages, chopping them into bits and then pulling random features/syntax/semantics at random from the various different piles. Those bits where then stuck together with duct tape and bubble gum and called PHP... As one of the contractors who wrote some of the PHP said: PHP is like the worst parts of shell, Perl, and Java all combined into one language! I can't remember where I read it, and I definitely don't know if it's accurate to current thinking, but the other day I found a quote purporting to be from the creator of PHP saying that he didn't care about memory leaks, just restart Apache periodically. It's definitely true of most PHP scripts that they're unconcerned about resource leakage, on the assumption that everything'll get cleared out at the end of a page render. PHP seems to encourage sloppiness. Fair enough, but it's the M in the LAMP stack I object to. I'd much rather have P. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
Fair enough, but it's the M in the LAMP stack I object to. I'd much rather have P. +1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 9:05 PM, Jason Friedman wrote: Fair enough, but it's the M in the LAMP stack I object to. I'd much rather have P. +1 I know this isn't the list for database discussions, but I've never gotten a decent answer. I don't know much about either, so I'm kind of curious why postgresql over mysql? -- 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/27/2012 9:05 PM, Jason Friedman wrote: Fair enough, but it's the M in the LAMP stack I object to. I'd much rather have P. +1 I know this isn't the list for database discussions, but I've never gotten a decent answer. I don't know much about either, so I'm kind of curious why postgresql over mysql? I'll try not to get too OT... I had previously just used MySQL (and SQLite), but have been reaading some PostGres stuff lately. I took a look around and basically... you and I won't know or notice a difference probably ever. There's all sorts of crazy tweaks you can get for reliability, speed, and backups depending on what you use. So the only advice I can give on that is just learn to use both. And even better yet, just use SQLAlchemy if you're ever touching a database from Python because it handles all the mucky SQL for you - you just define the ORM. (Hey look! A Python module!) My $0.02 -Wayne -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 10:14 PM, Littlefield, Tyler ty...@tysdomain.com wrote: I know this isn't the list for database discussions, but I've never gotten a decent answer. I don't know much about either, so I'm kind of curious why postgresql over mysql? MySQL is an open-source PRODUCT owned by a for-profit company. PostgreSQL is an open-source PROJECT and is unowned. A lot of the major technical differences are outlined here: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL -- Greg Donald -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner wa...@waynewerner.com wrote: the only advice I can give on that is just learn to use both. I find there's little to lose in having experience with both. Most every good web framework out there supports lots of different databases through generic ORM layers.. so flipping back and forth to see which database is better for your particular app and workload is trivial. -- Greg Donald -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Fri, Sep 28, 2012 at 2:12 PM, Greg Donald gdon...@gmail.com wrote: On Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner wa...@waynewerner.com wrote: the only advice I can give on that is just learn to use both. I find there's little to lose in having experience with both. Most every good web framework out there supports lots of different databases through generic ORM layers.. so flipping back and forth to see which database is better for your particular app and workload is trivial. Learning both is good, if for no reason than that learning more tends to be advantageous. As Greg said in his other post, PGSQL is a completely open source project. That's a significant point imho. Other points to consider: * MySQL is designed for dynamic web sites, with lots of reading and not too much writing. Its row and table locking system is pretty rudimentary, and it's quite easy for performance to suffer really badly if you don't think about it. But if your needs are simple, MySQL is probably enough. PostgreSQL uses MVCC to avoid locks in many cases. You can happily read from a row while it's being updated; you'll be unaware of the update until it's committed. * Postgres has solid support for advanced features like replication. I don't know how good MySQL's replication is, never tried it. Can't say. This might be completely insignificant. * The default MySQL engine, MyISAM, doesn't do proper transaction logging etc. InnoDB is better for this, but the internal tables (where your database *structure* is maintained) are MyISAM. This imposes a definite risk. * Both engines have good support in popular languages, including (dragging this back on topic, kicking and screaming) Python. For further details, poke around on the web; I'm sure you'll find plenty of good blog posts etc. But as for me and my house, we will have Postgres serve us. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 9/27/2012 10:37 PM, Chris Angelico wrote: On Fri, Sep 28, 2012 at 2:12 PM, Greg Donald gdon...@gmail.com wrote: On Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner wa...@waynewerner.com wrote: the only advice I can give on that is just learn to use both. I find there's little to lose in having experience with both. Most every good web framework out there supports lots of different databases through generic ORM layers.. so flipping back and forth to see which database is better for your particular app and workload is trivial. I plan to do that, just so I have both. I've had the experience of mysql, so I guess postgresql is up next. I was just really curious why so many people prefered it. Perhaps off topic (actually really off topic), but if I were to dump my tables from mysql out into flat-files, does postgresql use the same basic structure? IIRC there's a sql98 standard or something like that. Learning both is good, if for no reason than that learning more tends to be advantageous. As Greg said in his other post, PGSQL is a completely open source project. That's a significant point imho. Other points to consider: * MySQL is designed for dynamic web sites, with lots of reading and not too much writing. Its row and table locking system is pretty rudimentary, and it's quite easy for performance to suffer really badly if you don't think about it. But if your needs are simple, MySQL is probably enough. PostgreSQL uses MVCC to avoid locks in many cases. You can happily read from a row while it's being updated; you'll be unaware of the update until it's committed. * Postgres has solid support for advanced features like replication. I don't know how good MySQL's replication is, never tried it. Can't say. This might be completely insignificant. * The default MySQL engine, MyISAM, doesn't do proper transaction logging etc. InnoDB is better for this, but the internal tables (where your database *structure* is maintained) are MyISAM. This imposes a definite risk. You've lost me here; there are two different engines. From what I got from your post, innoDB just essentially wraps MyIsam with some pretty (or apparently not so pretty) locking stuff to help with transactions? * Both engines have good support in popular languages, including (dragging this back on topic, kicking and screaming) Python. For further details, poke around on the web; I'm sure you'll find plenty of good blog posts etc. But as for me and my house, we will have Postgres serve us. Will do, thanks for all the feedback (both on and off list). I'm not a huge database person; I've never really played around with much of it since there's a lot more to understand and I can't just mess with it like any other language, so I was unaware of a lot, and still am in terms of performance. I've obviously seen a ton of blog posts talking about the differences, but they tend to dive into the inner mechanics, something which I don't understand all that well. PS: Someone mentioned my messages were not indented properly; is this still the case? Apparently thunderbird allows ctrl+right bracket to outdent, so I assume my messages should be the outer ones with others being indented farther. ChrisA -- 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 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: 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: 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
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
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: 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
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: 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: 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: 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: 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
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: 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: 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: 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: 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: 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: 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: 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: 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
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
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
