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, Sep 27, 2012 at 8:59 PM, alex23 wrote: > On Sep 28, 2:17 am, Devin Jeanpierre 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 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 Sat, Sep 29, 2012 at 1:14 AM, Ian Kelly wrote: > On Fri, Sep 28, 2012 at 8:58 AM, Chris Angelico 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 Fri, Sep 28, 2012 at 8:58 AM, Chris Angelico 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 12:31 AM, Dennis Lee Bieber wrote: > On Fri, 28 Sep 2012 14:37:21 +1000, Chris Angelico > 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 Sep 28, 5:54 pm, Steven D'Aprano wrote: > On Fri, 28 Sep 2012 05:08:24 -0700, rusi wrote: > > On Sep 27, 5:11 pm, Devin Jeanpierre wrote: > >> On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano > > >> 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 Fri, 28 Sep 2012 05:08:24 -0700, rusi wrote: > On Sep 27, 5:11 pm, Devin Jeanpierre wrote: >> On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano >> >> 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 27, 5:11 pm, Devin Jeanpierre wrote: > On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano > > 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 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
>>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
in 681910 20120927 131113 Devin Jeanpierre wrote: >On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano > 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
On 9/27/2012 10:37 PM, Chris Angelico wrote: On Fri, Sep 28, 2012 at 2:12 PM, Greg Donald wrote: On Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner 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 Fri, Sep 28, 2012 at 2:12 PM, Greg Donald wrote: > On Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner 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 Thu, Sep 27, 2012 at 10:37 PM, Wayne Werner 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 Thu, Sep 27, 2012 at 10:14 PM, Littlefield, Tyler 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 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 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
> 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 Fri, 28 Sep 2012 00:32:58 +1000, Chris Angelico wrote: > On Thu, Sep 27, 2012 at 11:59 PM, Grant Edwards > wrote: >> On 2012-09-27, Chris Angelico wrote: >>> On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano >>> 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
On Sep 28, 2:17 am, Devin Jeanpierre 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 Sep 28, 2:47 am, Mark Lawrence 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
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, 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 "(1<<5)+1" will be executed much faster than "(1<<500)+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 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
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
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 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
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
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/2012 17:49, Chris Angelico wrote: On Fri, Sep 28, 2012 at 2:45 AM, Mark Lawrence 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
On Thu, Sep 27, 2012 at 12:45 PM, Mark Lawrence 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 Fri, Sep 28, 2012 at 2:45 AM, Mark Lawrence 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 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 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: On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano 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 Thu, Sep 27, 2012 at 10:25 AM, Steven D'Aprano 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 >> 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 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 4:43 AM, Alex Strickland 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 Thu, Sep 27, 2012 at 11:59 PM, Grant Edwards wrote: > On 2012-09-27, Chris Angelico wrote: >> On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano >> 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, 27 Sep 2012 08:11:13 -0400, Devin Jeanpierre wrote: > On Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano > 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 2012-09-27, Chris Angelico wrote: > On Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano > 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 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 Thu, Sep 27, 2012 at 2:13 AM, Steven D'Aprano 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
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 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
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 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 Thu, Sep 27, 2012 at 4:01 PM, Steven D'Aprano 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 Thu, 27 Sep 2012 15:37:35 +1000, Chris Angelico wrote: > On Thu, Sep 27, 2012 at 10:44 AM, Steven D'Aprano > 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 10:44 AM, Steven D'Aprano wrote: > PyPy is, well, PyPy is amazing, if you have the hardware to run it. It is > an optimizing Python JIT compiler, and it can consistently demonstrate > speeds of about 10 times the speed of CPython, which puts it in the same > ballpark as native code generated by Java compilers. For some (admittedly > artificially narrow) tasks it can beat optimized C code. It's fast enough > for real time video processing, depending on the algorithm used. > > 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? I'd much rather have full Unicode support etc etc etc than the coolness of Python-implemented-in-Python, even with a significant performance boost. > I expect that, within the decade, PyPy will become "the" standard Python > compiler and CPython will be relegated to "merely" the reference > implementation. 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. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, 26 Sep 2012 17:14:44 -0700, alex23 wrote: > On Sep 26, 10:17 pm, wxjmfa...@gmail.com wrote: >> Notice, I'm not a Unicode illiterate > > Any chance you could work on your usenet literacy and fix your double > posts? I have a better idea: Consign him to the same bin as Dwight Hutto and Dihedral. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 27, 6:27 am, Terry Reedy wrote: > On 9/26/2012 4:45 AM, Dwight Hutto wrote: > > my ego > Uh, Dwight, he was not talking to you. The irony, it is so rich :) -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On 27/09/2012 01:40, Steven D'Aprano wrote: On Wed, 26 Sep 2012 10:01:11 +0100, Mark Lawrence wrote: You remind me of the opening to the song Plaistow Patricia by Ian Dury and the Blockheads. While I always appreciate a good reference to Ian Dury, please stop feeding D.H.'s ego by responding to his taunts. Good point as he's had so much rope that he's hung himself several times over. Thanks for helping me get my feet back on the ground. -- Cheers. Mark Lawrence. -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, 26 Sep 2012 10:01:11 +0100, Mark Lawrence wrote: > You remind me of the opening to the song Plaistow Patricia by Ian Dury > and the Blockheads. While I always appreciate a good reference to Ian Dury, please stop feeding D.H.'s ego by responding to his taunts. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Wed, 26 Sep 2012 09:30:19 -0400, Kevin Walzer wrote: > 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? The "Big Four" are CPython, Jython, IronPython and PyPy. Possibly "Big Five" if you include Stackless, although I'm not quite sure just how big (popular) Stackless actually is. It's certainly old and venerable, and actively maintained. If you've played EVE Online, you've seen Stackless in action. Jython has a big constituency in Java shops. I can't tell you much about that because I don't use Java. PyPy is, well, PyPy is amazing, if you have the hardware to run it. It is an optimizing Python JIT compiler, and it can consistently demonstrate speeds of about 10 times the speed of CPython, which puts it in the same ballpark as native code generated by Java compilers. For some (admittedly artificially narrow) tasks it can beat optimized C code. It's fast enough for real time video processing, depending on the algorithm used. 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. I expect that, within the decade, PyPy will become "the" standard Python compiler and CPython will be relegated to "merely" the reference implementation. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Article on the future of Python
On Sep 26, 10:17 pm, wxjmfa...@gmail.com wrote: > Notice, I'm not a Unicode illiterate Any chance you could work on your usenet literacy and fix your double posts? -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Re: Article on the future of Python
On Thu, Sep 27, 2012 at 9:29 AM, Terry Reedy wrote: > On 9/26/2012 2:58 PM, Ian Kelly wrote: > >> You know, usually when I see software decried as America-centric, it's >> because it doesn't support Unicode. This must be the first time I've >> seen that label applied to software that dares to *fully* support Unicode. > > > What is truly bizarre is the idea came from and much or most of the > implementation was done by Europeans, not Americans. I suppose that a system that supports only Latin-1 is therefore Italy-centric? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Fwd: Re: Article on the future of Python
On 9/26/2012 2:58 PM, Ian Kelly wrote: You know, usually when I see software decried as America-centric, it's because it doesn't support Unicode. This must be the first time I've seen that label applied to software that dares to *fully* support Unicode. What is truly bizarre is the idea came from and much or most of the implementation was done by Europeans, not Americans. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: 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: 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 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
Fwd: Re: Article on the future of Python
Resending to the list. -- Forwarded message -- From: "Ian Kelly" Date: Sep 26, 2012 12:57 PM Subject: Re: Article on the future of Python To: On Sep 26, 2012 12:42 AM, 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
Le mercredi 26 septembre 2012 18:52:44 UTC+2, Paul Rubin a écrit : > Chris Angelico 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
Re: Article on the future of Python
Chris Angelico 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
On Thu, Sep 27, 2012 at 2:52 AM, Paul Rubin wrote: > Chris Angelico 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 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
Chris Angelico wrote: On Wed, Sep 26, 2012 at 10:19 PM, 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
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 > > 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
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
On Wed, Sep 26, 2012 at 1:23 AM, Steven D'Aprano 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
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
Le mercredi 26 septembre 2012 16:56:55 UTC+2, Chris Angelico a écrit : > On Thu, Sep 27, 2012 at 12:50 AM, 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
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
On Thu, Sep 27, 2012 at 12:50 AM, 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
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:19 AM, 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
Le mercredi 26 septembre 2012 11:55:16 UTC+2, Chris Angelico a écrit : > On Wed, Sep 26, 2012 at 7:31 PM, 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 Wed, Sep 26, 2012 at 11:43 PM, 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. 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
On Wed, Sep 26, 2012 at 10:19 PM, 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. Would you believe... barely slower? 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 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 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 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 26/09/2012 14:01, Roy Smith wrote: In article , Hannu Krosing 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 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
In article , Hannu Krosing 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
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
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
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 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
On Wed, Sep 26, 2012 at 7:31 PM, 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
>> >> 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
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
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
>> 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 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
> 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
> > 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
On Wed, Sep 26, 2012 at 6:34 PM, Mark Lawrence 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
On 26/09/2012 08:44, Chris Angelico wrote: On Wed, Sep 26, 2012 at 5:39 PM, Dwight Hutto wrote: On Wed, Sep 26, 2012 at 3:17 AM, Ethan Furman 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 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 05:10, Chris Angelico wrote: On Wed, Sep 26, 2012 at 10:54 AM, Steven D'Aprano 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 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