I Am Worried About The Future Of Python(ironfroggy.com)
ironfroggy.com
I Am Worried About The Future Of Python
http://www.ironfroggy.com/software/i-am-worried-about-the-future-of-python
207 comments
I would just like to make people aware that there is one mobile platform that does ship with Python support: BlackBerry 10 and the BlackBerry PlayBook.
It ships with Python 3.2 on device, and it can be used to develop actual apps with. Games are possible too, I know someone working on one right now.
You should check out our project's site at http://blackberry-py.microcode.ca/. I'm one of the lead contributors, and the project is still very much in its infancy.
I'm actually in San Jose right now for the BlackBerry Jam Americas conference if you'd like to meet up and discuss more.
It ships with Python 3.2 on device, and it can be used to develop actual apps with. Games are possible too, I know someone working on one right now.
You should check out our project's site at http://blackberry-py.microcode.ca/. I'm one of the lead contributors, and the project is still very much in its infancy.
I'm actually in San Jose right now for the BlackBerry Jam Americas conference if you'd like to meet up and discuss more.
Tell the other two people there we said hi.
OK, that's mean, but seriously the installed base of BlackBerry doesn't really inspire confidence.
OK, that's mean, but seriously the installed base of BlackBerry doesn't really inspire confidence.
Symbian and Maemo/Meego also supported Python. I remember having Python interpreter on my 2005 vintage phone :)
Why do you even try to ship on Python 3? Python 2.7 is far from old. You don't have to use the latest of everything.
I've been using Python for almost 10 years, and mostly I've pretended that Python 3 doesn't exist so far :) That simplifies life in many ways.
I had no idea that people even ran Python on iOS, but if so it's cool that it even works!
It's not true that Pythonic programs can't use multiple cores. In many programs a lot of time is spent in C extensions (i.e. half the stdlib), where the GIL is released, so you can run in parallel fine in that case. Not to say you won't be bottlenecked, but don't write it off so quickly.
I've been using Python for almost 10 years, and mostly I've pretended that Python 3 doesn't exist so far :) That simplifies life in many ways.
I had no idea that people even ran Python on iOS, but if so it's cool that it even works!
It's not true that Pythonic programs can't use multiple cores. In many programs a lot of time is spent in C extensions (i.e. half the stdlib), where the GIL is released, so you can run in parallel fine in that case. Not to say you won't be bottlenecked, but don't write it off so quickly.
Two reasons:
1) New ports (e.g., WinRT) are all going to be Python 3.X
2) All improvements (performance, memory size) are going in Python 3.X
Overall, Python 2.7 certainly works. But it's a wasting asset, and so is any codebase stuck on it.
1) New ports (e.g., WinRT) are all going to be Python 3.X
2) All improvements (performance, memory size) are going in Python 3.X
Overall, Python 2.7 certainly works. But it's a wasting asset, and so is any codebase stuck on it.
> Windows 8 launches Oct 26; Python is frankly just not ready, and no one but Martin L and a few others seem to care (or even notice).
Part of the problem is that you could count on one hand the number of contributors who have worked on non-trivial Windows issues in CPython in the last 12 months (probably even 24). I think we're pretty aware of this, but there are still only 24 hours in a day.
In fact, my new SSD should be arriving today to complete the build of my new machine, and Martin's work on WinRT probably jumps ahead on my todo list.
Part of the problem is that you could count on one hand the number of contributors who have worked on non-trivial Windows issues in CPython in the last 12 months (probably even 24). I think we're pretty aware of this, but there are still only 24 hours in a day.
In fact, my new SSD should be arriving today to complete the build of my new machine, and Martin's work on WinRT probably jumps ahead on my todo list.
I don't think the main issue from OP is that WinRT support is not ready yet: windows 8 is not even out yet. The fact that he will have to migrate to python 3 to get there seems to be the main issue.
Correct that it's not the main issue, which is why I quoted the part I was responding to...
This lack of contributors would not have been as a serious problem without the insistence to break backwards compatibility and fork efforts for five (and counting) years: it sounds like the work got done, it is just for the "wrong version" (the one few people can use) of Python.
Sweet! Thanks to both of you for your WinRT porting work. Agreed about the duration of the day. :)
I realize this is going to be an unpopular opinion, but I think that for the long term sake of the language, the 3.x schism was bad, and will ultimately be regarded as a big mistake.
In the time the community has spent dealing with/bickering about the transition, other languages have continued to forge ahead, while python just hasn't kept pace.
It hurts me to say that - I like python a lot, but lately it just doesn't seem to have it's mojo.
In the time the community has spent dealing with/bickering about the transition, other languages have continued to forge ahead, while python just hasn't kept pace.
It hurts me to say that - I like python a lot, but lately it just doesn't seem to have it's mojo.
You should avoid making technical decisions based on emotional impulses.
Technically Python 3 is superior, IMO, to Python 2.7 and barring any setbacks such as unported libraries (which are becoming increasingly scarce) I wouldn't start a new project in Python 2.7.
The reason libraries have been taking so long is because so many people are resistant to change that they hadn't begun making any serious efforts to port to Python 3 until 2011 by my estimation.
Python 2 is so ass-backwards and broken that I find it painful to use on large code bases. It conflates strings and byte streams, has pathetic Unicode support, and its libraries are rife with bit-rotting code. For the batteries to continue being useful they need to be updated once in a while. Have you seen urllib? It's atrocious by today's standards! Python needed an update and I think that the core team made the right choices.
The challenge has been porting and the core team knew that. They made some poor decisions in hind-sight such as 2to3 and dropping u"", but otherwise the porting story is not as painful as it seems. Cherrypy did it ages ago and Django is finally getting around to it. SQLAlchemy supports Python 3. There are fewer reasons not to switch than ever before and yet articles like this still come up to this day.
Python is only going to fall by the way-side if the developers of the language decide to stop using it. The language hasn't gotten worse by any stretch of the imagination. It needs more contributors to make it better. If you like it so much, port your libraries, contribute to python core, and stop complaining! It's been like five years people!
Technically Python 3 is superior, IMO, to Python 2.7 and barring any setbacks such as unported libraries (which are becoming increasingly scarce) I wouldn't start a new project in Python 2.7.
The reason libraries have been taking so long is because so many people are resistant to change that they hadn't begun making any serious efforts to port to Python 3 until 2011 by my estimation.
Python 2 is so ass-backwards and broken that I find it painful to use on large code bases. It conflates strings and byte streams, has pathetic Unicode support, and its libraries are rife with bit-rotting code. For the batteries to continue being useful they need to be updated once in a while. Have you seen urllib? It's atrocious by today's standards! Python needed an update and I think that the core team made the right choices.
The challenge has been porting and the core team knew that. They made some poor decisions in hind-sight such as 2to3 and dropping u"", but otherwise the porting story is not as painful as it seems. Cherrypy did it ages ago and Django is finally getting around to it. SQLAlchemy supports Python 3. There are fewer reasons not to switch than ever before and yet articles like this still come up to this day.
Python is only going to fall by the way-side if the developers of the language decide to stop using it. The language hasn't gotten worse by any stretch of the imagination. It needs more contributors to make it better. If you like it so much, port your libraries, contribute to python core, and stop complaining! It's been like five years people!
Sorry in advance that this is so negative, but it reflects my honest feelings, as well as some experience.
The big problem with Python was always predicting what any given piece of code would actually do. Considering the lack of static typing, pervasive use of exceptions for non-exceptional cases, and subtle behavior changes in the core language from version to version, you basically never knew what you were going to get. On the plus side, all the Python libraries I ever used were open source and the code was easy to access. On the minus side, I needed to access that code on a daily or even hourly basis. Getting something working on my own machine wasn't too hard. Getting something working on anyone else's computer was a challenge.
It seems that most Python developers now use virtualenv. This is a handy little tool that creates a small runtime environment for your Python program. Basically, it allows you to explicitly set the version of every library that you use.
I always viewed virtualenv as a sign of Python's failure. Having stable APIs is damn near impossible in Python, so let's just give up and use old versions for everything. Put the whole mess in an airtight chamber, and hope you never need to do anything with it in the future. With an attitude like this, it's no surprise that the adoption of Python 3 has been pushed off into the indefinite future.
Issues like the global interpreter lock (GIL) and lack of real GC for data structures with cycles just reinforce the impression of a better /bin/sh, not a serious language. Sadly, in some ways, Bourne shell is still the better language, because it got backwards compatibility right, has a bigger install base, and better startup time. It's also significantly less verbose for simple tasks. And really, if your task isn't simple-- you shouldn't be using a language that doesn't even properly support threads.
tl;dr: Overall, I think my interest in Python has come to an end. It's over, sorry.
The big problem with Python was always predicting what any given piece of code would actually do. Considering the lack of static typing, pervasive use of exceptions for non-exceptional cases, and subtle behavior changes in the core language from version to version, you basically never knew what you were going to get. On the plus side, all the Python libraries I ever used were open source and the code was easy to access. On the minus side, I needed to access that code on a daily or even hourly basis. Getting something working on my own machine wasn't too hard. Getting something working on anyone else's computer was a challenge.
It seems that most Python developers now use virtualenv. This is a handy little tool that creates a small runtime environment for your Python program. Basically, it allows you to explicitly set the version of every library that you use.
I always viewed virtualenv as a sign of Python's failure. Having stable APIs is damn near impossible in Python, so let's just give up and use old versions for everything. Put the whole mess in an airtight chamber, and hope you never need to do anything with it in the future. With an attitude like this, it's no surprise that the adoption of Python 3 has been pushed off into the indefinite future.
Issues like the global interpreter lock (GIL) and lack of real GC for data structures with cycles just reinforce the impression of a better /bin/sh, not a serious language. Sadly, in some ways, Bourne shell is still the better language, because it got backwards compatibility right, has a bigger install base, and better startup time. It's also significantly less verbose for simple tasks. And really, if your task isn't simple-- you shouldn't be using a language that doesn't even properly support threads.
tl;dr: Overall, I think my interest in Python has come to an end. It's over, sorry.
One nitpick:
> lack of real GC for data structures with cycles
This has not been true since (AFAIK) Python 2.0, which was released 12 years ago.
> lack of real GC for data structures with cycles
This has not been true since (AFAIK) Python 2.0, which was released 12 years ago.
> > lack of real GC for data structures with cycles
> This has not been true since (AFAIK) Python 2.0,
> which was released 12 years ago.
Sorta.
It seems that CPython still can't garbage collect objects in cycles if those objects have a __del__ method.
See http://www.electricmonk.nl/log/2008/07/07/python-destructor-...
Or see gc.garbage, from http://docs.python.org/release/2.7.3/library/gc.html
Sorta.
It seems that CPython still can't garbage collect objects in cycles if those objects have a __del__ method.
See http://www.electricmonk.nl/log/2008/07/07/python-destructor-...
Or see gc.garbage, from http://docs.python.org/release/2.7.3/library/gc.html
But what other way there was? It's all about Unicode - it HAS to be resolved at some point, and if what I read is correct than there was no way to make this transition smooth(er). I'm not familiar witr Ruby at all, but I heard there was similar breakage between major versions lately?
The changes were gratuitous, and there were numerous ways of making it happen more smoothly; for an example of a community that handled it much better, just take a look at Ruby 1.9: they have great uptake.
To take a really trivial example: the name "str" should not have been reused to mean "unicode", it either should have continued to mean "bytes" or it should have been dropped altogether.
Certainly, under no circumstance, should the name "unicode" have been removed, but it was; they also should not have removed the u'' syntax. Their goal wasn't just "fix things" it was "break old things".
The result is that it is nearly impossible to write code that runs on both Python 2.x and Python 3.x even when the semantics of the code have absolutely nothing to do with the things people really wanted to change.
Another great example of this is the exception syntax: they changed the way you catch exceptions to replace the "," with "as"; less confusing, sure, but again it means that you can't write code that works on both.
The answer to this was then a tool "2to3" which smoothed over some of the more obvious problems, but whose entire mission statement was flawed: to keep all code in Python 2, supporting Python 3 as a second-class citizen.
A lot of these changes, certainly the syntax ones, could easily have been made per-file: make new scripts .py3 or have a special header, or force old scripts to have a special command line argument or special load path.
At least then, you could mix and match new and old code without simply being stuck in the limbo that is Python 2.7... a limbo that didn't even help the cause, as you can't even write fully 2.7/3.x compatible code.
The result is that we still have tons of libraries that don't work. When they do, they often have less testing. When they are well tested, they often "took the opportunity" (just like Python itself, which set the bad expectation) to have different semantics, so you have to port your code anyway.
To take a really trivial example: the name "str" should not have been reused to mean "unicode", it either should have continued to mean "bytes" or it should have been dropped altogether.
Certainly, under no circumstance, should the name "unicode" have been removed, but it was; they also should not have removed the u'' syntax. Their goal wasn't just "fix things" it was "break old things".
The result is that it is nearly impossible to write code that runs on both Python 2.x and Python 3.x even when the semantics of the code have absolutely nothing to do with the things people really wanted to change.
Another great example of this is the exception syntax: they changed the way you catch exceptions to replace the "," with "as"; less confusing, sure, but again it means that you can't write code that works on both.
The answer to this was then a tool "2to3" which smoothed over some of the more obvious problems, but whose entire mission statement was flawed: to keep all code in Python 2, supporting Python 3 as a second-class citizen.
A lot of these changes, certainly the syntax ones, could easily have been made per-file: make new scripts .py3 or have a special header, or force old scripts to have a special command line argument or special load path.
At least then, you could mix and match new and old code without simply being stuck in the limbo that is Python 2.7... a limbo that didn't even help the cause, as you can't even write fully 2.7/3.x compatible code.
The result is that we still have tons of libraries that don't work. When they do, they often have less testing. When they are well tested, they often "took the opportunity" (just like Python itself, which set the bad expectation) to have different semantics, so you have to port your code anyway.
[deleted]
I think it's a little unfair to point to Ruby as an example of a community getting it right. The motivation behind the 1.8-to-1.9 shift for a lot of people was the markedly better VM in 1.9 (which is roughly comparable to CPython, as it happens), and not necessarily the language features. Specifically the encoding situation in Ruby 1.9 is... interesting, and easy to find surprising edge cases in.
Also Ruby had a far smaller deployment and library base to convert. Get Rails and Sinatra ported and you're mostly there. There are as far as I know no significant commercial software that ships with ruby as its main scripting language. Ruby doesn't really have its equivalent of numpy and friends which has snaked its way into critical software in just about every field you care to mention. Ruby 1.8 -> 1.9 was more like Python 1.X-2.X
There is a difference between "right" and "much better" (the term I used). I was able to upgrade my code to use Ruby 1.9 trivially, and the result still worked fine on Ruby 1.8. The transition was downright painless for almost everyone involved. (Disclosure: I am the Jay Freeman mentioned in the thank you at the bottom of Yehuda's article on the Ruby 1.9 encoding changes and how they would and did affect Rails.)
I think that is sort of the point.
There was a carrot (better performance) to go with the stick.
Python 3 was pretty much all stick, unless you were a unicode fetishist.
There was a carrot (better performance) to go with the stick.
Python 3 was pretty much all stick, unless you were a unicode fetishist.
You are right about the u"" syntax. Thankfully, Python 3.3 supports it again.
The "except .. as" clause was backported to Python 2.6, which was released almost 4 years ago. If you don't need to support Python 2.5 then you can migrate to except..as right now. Python 2.6 added "from __future__ import print_function", and so on.
The goal was and is to make Python 2.7 a migration to a 3.x. People have and do write code which is usable, and unchanged, in both major version, which seems to contradict your statement that doing so isn't possible. And people continue to work to make that easier, while also advancing Python as a language.
Your proposal, to be able to "mix and match new and old code", does not work. At least, not without a lot more development effort behind it. The object models are different enough to make it not work. Remember, Python 2 has both old-style and new-style classes, while Python 3 does not. There's Python 2 code which probably still depends on Python 2 old-style classes, and will break. Which means you're left only being able to support the subset that the Python core developers, and those who wish to become core developers want to support. Which is what we have now.
The "except .. as" clause was backported to Python 2.6, which was released almost 4 years ago. If you don't need to support Python 2.5 then you can migrate to except..as right now. Python 2.6 added "from __future__ import print_function", and so on.
The goal was and is to make Python 2.7 a migration to a 3.x. People have and do write code which is usable, and unchanged, in both major version, which seems to contradict your statement that doing so isn't possible. And people continue to work to make that easier, while also advancing Python as a language.
Your proposal, to be able to "mix and match new and old code", does not work. At least, not without a lot more development effort behind it. The object models are different enough to make it not work. Remember, Python 2 has both old-style and new-style classes, while Python 3 does not. There's Python 2 code which probably still depends on Python 2 old-style classes, and will break. Which means you're left only being able to support the subset that the Python core developers, and those who wish to become core developers want to support. Which is what we have now.
> Remember, Python 2 has both old-style and new-style classes, while Python 3 does not.
This logic is circular: you are directly claiming that Python 3 could not mix and match support with Python 2 because Python 3 does not support mixing and matching features with those from Python 2. Yes: I realize that, and that is precisely what I am taking issue with.
The reality is that supporting many of these features is actually quite simple. Please realize before disagreeing: I develop compilers, and I have developed virtual machines. I know what kind of effort it takes to have parameterized grammars and internal transformations.
What really seems to happen with Python is that people get it in their heads "developers should not be using this old feature", and then it gets actively removed in order to clear the mental space for the features that should be used: a "there's only one way to do it" mentality.
However, there is code out there that is using that feature, and that code might not have a maintainer anymore; that code works, has been battle-hardened, and the only thing keeping anyone from using it is now some arbitrary syntax change that was pushed through.
For an example of a community that gets this: C. No one develops in K&R C anymore. However, there is still tons of code out there, even code inside of some core projects you use every day, that was written in K&R C and never needed to get serious modifications made.
That code still works, and still compiles with modern C compilers. While the syntax is quite different, it really does not take much time to make certain your compiler supports it, and you suddenly have access to all of this totally working code: this should be considered a "win".
Yet, something in the Python community seems to latch on to the idea that that situation is actually a "lose": that having support for old features is only something that should be done in Python 3.3 (which isn't even out yet) as a concession to some reality as opposed to out-of-the-gate in 3.0.
Can you help explain this one to me? Why is it possible for Python 2.7 to have all of these really cool "from __future__ import" features, but impossible for Python 3 to have just a couple "from __past__ import" features? The only answer I currently have is "stubborness".
(Also, on the exception-handling semantics, it is only this year that a lot of key projects, from Jython to App Engine, have supported anything but Python 2.5; I accept that it is nice that 2.6 supported it, but a lot of real-world/serious Python was stuck in 2.5, so if you want your library to be widely used you couldn't use that syntax. The sea-change on this seemed to happen this year, so this should increasingly not be an issue, but it is way way too late and could have been remedied by supporting that syntax with a switch.)
(The same kind of failure, for the record, is demonstrated in the decision to finally fix a few of these issues--the u'' syntax not being the only one--in Python 3.3. Python 3.3 is not even out yet; when it is, it will not be deployed in many places, even places where Python 3.2 already is, such as the numerous Ubuntu servers that are already deployed. If Python wants to be serious about helping developers and making Python 3 actually happen, they should backport that change to Python 3.2 so it can be pushed through major distributions; otherwise, it just delays the benefits by yet another year, if not longer.)
This logic is circular: you are directly claiming that Python 3 could not mix and match support with Python 2 because Python 3 does not support mixing and matching features with those from Python 2. Yes: I realize that, and that is precisely what I am taking issue with.
The reality is that supporting many of these features is actually quite simple. Please realize before disagreeing: I develop compilers, and I have developed virtual machines. I know what kind of effort it takes to have parameterized grammars and internal transformations.
What really seems to happen with Python is that people get it in their heads "developers should not be using this old feature", and then it gets actively removed in order to clear the mental space for the features that should be used: a "there's only one way to do it" mentality.
However, there is code out there that is using that feature, and that code might not have a maintainer anymore; that code works, has been battle-hardened, and the only thing keeping anyone from using it is now some arbitrary syntax change that was pushed through.
For an example of a community that gets this: C. No one develops in K&R C anymore. However, there is still tons of code out there, even code inside of some core projects you use every day, that was written in K&R C and never needed to get serious modifications made.
That code still works, and still compiles with modern C compilers. While the syntax is quite different, it really does not take much time to make certain your compiler supports it, and you suddenly have access to all of this totally working code: this should be considered a "win".
Yet, something in the Python community seems to latch on to the idea that that situation is actually a "lose": that having support for old features is only something that should be done in Python 3.3 (which isn't even out yet) as a concession to some reality as opposed to out-of-the-gate in 3.0.
Can you help explain this one to me? Why is it possible for Python 2.7 to have all of these really cool "from __future__ import" features, but impossible for Python 3 to have just a couple "from __past__ import" features? The only answer I currently have is "stubborness".
(Also, on the exception-handling semantics, it is only this year that a lot of key projects, from Jython to App Engine, have supported anything but Python 2.5; I accept that it is nice that 2.6 supported it, but a lot of real-world/serious Python was stuck in 2.5, so if you want your library to be widely used you couldn't use that syntax. The sea-change on this seemed to happen this year, so this should increasingly not be an issue, but it is way way too late and could have been remedied by supporting that syntax with a switch.)
(The same kind of failure, for the record, is demonstrated in the decision to finally fix a few of these issues--the u'' syntax not being the only one--in Python 3.3. Python 3.3 is not even out yet; when it is, it will not be deployed in many places, even places where Python 3.2 already is, such as the numerous Ubuntu servers that are already deployed. If Python wants to be serious about helping developers and making Python 3 actually happen, they should backport that change to Python 3.2 so it can be pushed through major distributions; otherwise, it just delays the benefits by yet another year, if not longer.)
Oops! I thought 3.3 was already out. I see it's only a release candidate.
Get this into your head - Python has a different development model than C. There is no standards body, or requirements for backwards compatibility. Anyone who gets into Python thinking that there will be full backwards compatibility is fooling themselves.
Those who want backwards compatibility can do so on one of several ways: 1) keep using the old code and don't upgrade, 2) contribute time, effort, and funding to the core developer team in order to implement backwards compatibility, 3) fork and maintain your own version of the source, 4) make your own run-time hooks to convert old-style Python code to the new-style runtime, or 5) create a new version of Python which does have that backwards compatibility.
I know that REXX and a few other languages have made a point of backwards compatibility even as semantics change. They have different goals, and a different funding model than Python. If enough people disagree, then those people can take the existing Python code base and run with it. But that's not happening. (I think there are some unofficial patches with VC2010 support, mostly used for internal company builds.)
There's, what, a few score people working part time in Python code development? Even Guido works on it only half time. How do you expect that small of a team to pull off a clean 3.0 release without making mistakes? The 3.0 release had a new io system, which was a lot slower than 2.x. There were a lot of bugs, like unicode filenames, which had to be figured out, where previously it was the responsibility of each developer to figure out the Unicode issues.
"Can you help explain this one to me? Why is it ... impossible for Python 3 to have just a couple "from __past__ import" features?"
That's an easy one. Lack of resources. The Python code developers did not want to maintain both old-style and new-style class implementations. They used Python 3 as a way to get rid of old-style. As a consequence too, it means that I can stop putting in the silly 'object' in "class Spam(object):", which was the Python 2 way of indicating that I wanted a new-style class. If 5 people said that they were willing to support old-style classes, and showed that they were committed to doing so for many years, then there may have been a different decision.
You can see that even in the PEP 3000, written during the 2.6 days: "But I expect there to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. This will to some extent depend on community demand for continued 2.x support, acceptance and stability of 3.0, and volunteer stamina." (Emphasis mine.)
So many other things had deeper semantic changes, like dict.keys returning a view rather than a list, that a simple syntax change is trivial. I don't think a "from __past__ import comma_exceptions" would have had much benefit. I can be wrong, but that's exactly the thing that the 2to3 converter could handle, and there are patches to make distutils convert 2.x code automatically and import hooks to do that transformation at run-time. One such is pymolurus.blogspot.com/2012/04/pep-414-like-import-hook-for-python-32.html . It isn't a catch-all solution, but that approach could help some people.
BTW, as far as I can tell, clang does not support K&R C.
Get this into your head - Python has a different development model than C. There is no standards body, or requirements for backwards compatibility. Anyone who gets into Python thinking that there will be full backwards compatibility is fooling themselves.
Those who want backwards compatibility can do so on one of several ways: 1) keep using the old code and don't upgrade, 2) contribute time, effort, and funding to the core developer team in order to implement backwards compatibility, 3) fork and maintain your own version of the source, 4) make your own run-time hooks to convert old-style Python code to the new-style runtime, or 5) create a new version of Python which does have that backwards compatibility.
I know that REXX and a few other languages have made a point of backwards compatibility even as semantics change. They have different goals, and a different funding model than Python. If enough people disagree, then those people can take the existing Python code base and run with it. But that's not happening. (I think there are some unofficial patches with VC2010 support, mostly used for internal company builds.)
There's, what, a few score people working part time in Python code development? Even Guido works on it only half time. How do you expect that small of a team to pull off a clean 3.0 release without making mistakes? The 3.0 release had a new io system, which was a lot slower than 2.x. There were a lot of bugs, like unicode filenames, which had to be figured out, where previously it was the responsibility of each developer to figure out the Unicode issues.
"Can you help explain this one to me? Why is it ... impossible for Python 3 to have just a couple "from __past__ import" features?"
That's an easy one. Lack of resources. The Python code developers did not want to maintain both old-style and new-style class implementations. They used Python 3 as a way to get rid of old-style. As a consequence too, it means that I can stop putting in the silly 'object' in "class Spam(object):", which was the Python 2 way of indicating that I wanted a new-style class. If 5 people said that they were willing to support old-style classes, and showed that they were committed to doing so for many years, then there may have been a different decision.
You can see that even in the PEP 3000, written during the 2.6 days: "But I expect there to be at least one or two new 2.x releases even after 3.0 (final) has been released, probably well into 3.1 or 3.2. This will to some extent depend on community demand for continued 2.x support, acceptance and stability of 3.0, and volunteer stamina." (Emphasis mine.)
So many other things had deeper semantic changes, like dict.keys returning a view rather than a list, that a simple syntax change is trivial. I don't think a "from __past__ import comma_exceptions" would have had much benefit. I can be wrong, but that's exactly the thing that the 2to3 converter could handle, and there are patches to make distutils convert 2.x code automatically and import hooks to do that transformation at run-time. One such is pymolurus.blogspot.com/2012/04/pep-414-like-import-hook-for-python-32.html . It isn't a catch-all solution, but that approach could help some people.
BTW, as far as I can tell, clang does not support K&R C.
"Get this through your head": the question here is about whether Python still has a chance of being successful, not whether they are bad people for what they did. My argument is firmly on the "no": Python is in decline after years of stagnation caused by a fork in their effort and I believe that they could have done some things differently at little effort to have had better chances.
Personally, I don't even have skin in the game anymore: I am now using Clojure, and am piecemeal porting my code over. This is actually an easier time than the brutal experience I had dealing with Python's / operator change (which I adopted ahead of schedule, thinking it would help me: all it did was hurt me as my code no longer could be used on 2.5).
I thereby wonder: what are you defending? Do you think Python is succeeding? That in another couple months we are going to suddenly hear of a massive turnaround? That it will still be relevant in another two years when 3.3 is fully deployed everywhere and most libraries might be Python 3 compatible? What is your overall position?
Personally, I don't even have skin in the game anymore: I am now using Clojure, and am piecemeal porting my code over. This is actually an easier time than the brutal experience I had dealing with Python's / operator change (which I adopted ahead of schedule, thinking it would help me: all it did was hurt me as my code no longer could be used on 2.5).
I thereby wonder: what are you defending? Do you think Python is succeeding? That in another couple months we are going to suddenly hear of a massive turnaround? That it will still be relevant in another two years when 3.3 is fully deployed everywhere and most libraries might be Python 3 compatible? What is your overall position?
You asked me a specific question. I said that the reason is the lack of resources. I didn't realize that we were talking about the decline and fall of the Python world.
I remember reading "Decline and Fall of the American Programmer." And "Rise and Resurrection of the American Programmer." It's a special kind of consultant who can get paid both coming and going.
Python is in decline? How do you reckon that? In my work, Python is the de factor high-level language for chemical informatics, molecular modeling, structure visualization, and the like. This is much improved over the last 10 years, and won't be dying in as short a time-span as two years in the future. No, most projects haven't migrated to Python 3. Yes, it will be annoying. So was porting client code from IRIX to Linux. That happens.
Really, you need to plan for it. And it sounds like you didn't plan for the division operator change. The ideas of that change first surfaced during user testing under the 1.x days, with Alice. That change decision was publicized in spring 2001, with PEP 238. The "from __future__ import division" was made available in Python 2.2. The runtime even has the -Q option so you can tell it to print warnings wherever there's a problem. The nice thing about this change is that it's purely a syntax issue which can be handled on a per-module basis, and mixed with modules which weren't compiled this way.
These all worked for 2.5, so what was the problem you experienced?
What I'm "defending" is my sense that Something is Wrong on the Internet. It sounds like you're doing things the wrong way. You expect certain behaviors which were never promised or implied, you don't read the update notices, and you don't use the tools which help you achieve the goals you want. No wonder you get so frustrated with Python! But I don't see what the Python developers could have done better, given the resources they had, and given that they care about goals that do not interest you.
You're going to run into the same problems with Clojure. Looking now, it seems that 1.3 broke code. Some things were removed, there were changes to the contrib namespace, and some third-party modules didn't work. Various places say it was a hassle to deal with. Sound familiar? How are you sure something like that will never happen again?
I remember reading "Decline and Fall of the American Programmer." And "Rise and Resurrection of the American Programmer." It's a special kind of consultant who can get paid both coming and going.
Python is in decline? How do you reckon that? In my work, Python is the de factor high-level language for chemical informatics, molecular modeling, structure visualization, and the like. This is much improved over the last 10 years, and won't be dying in as short a time-span as two years in the future. No, most projects haven't migrated to Python 3. Yes, it will be annoying. So was porting client code from IRIX to Linux. That happens.
Really, you need to plan for it. And it sounds like you didn't plan for the division operator change. The ideas of that change first surfaced during user testing under the 1.x days, with Alice. That change decision was publicized in spring 2001, with PEP 238. The "from __future__ import division" was made available in Python 2.2. The runtime even has the -Q option so you can tell it to print warnings wherever there's a problem. The nice thing about this change is that it's purely a syntax issue which can be handled on a per-module basis, and mixed with modules which weren't compiled this way.
These all worked for 2.5, so what was the problem you experienced?
What I'm "defending" is my sense that Something is Wrong on the Internet. It sounds like you're doing things the wrong way. You expect certain behaviors which were never promised or implied, you don't read the update notices, and you don't use the tools which help you achieve the goals you want. No wonder you get so frustrated with Python! But I don't see what the Python developers could have done better, given the resources they had, and given that they care about goals that do not interest you.
You're going to run into the same problems with Clojure. Looking now, it seems that 1.3 broke code. Some things were removed, there were changes to the contrib namespace, and some third-party modules didn't work. Various places say it was a hassle to deal with. Sound familiar? How are you sure something like that will never happen again?
> I didn't realize that we were talking about the decline and fall of the Python world.
The article is called "I Am Worried About The Future Of Python" and the specific thread I chose to participate in directly described a way that the Python 3 schism was contributing to the concern (WinRT support). To quote the lead comment for this thread: "I definitely feel like Python qua programming language has become a missed opportunity in many ways".
I then provided my experience, as someone who has been developing for over 20 years in numerous languages (even designing them and teaching them in a university setting), of a unique set of challenges and mistakes that I see Python having run across--a perspective that one reader called "a brilliant if unpopular analysis"--and yet I'm now simply being dragged into the same defensive argument that comes up whenever the 2/3 topic is breached: to turn it into a very personal attack against me and my abilities led by highly inflammatory and insulting wording like "get this into your head", quite despite the fact that I am hardly in the minority with regards to these overall opinions.
Regardless, I am hereby so confused as to what conversation you feel you are participating in that I am just going to bow out: thank you, regardless, for taking the time to respond.
(Oh, I will respond to the semi-unrelated Clojure discussion, as I should probably make certain I don't inadvertently cause them problems: I do not use third-party libraries written in Clojure, as there is really no need given that all of Java is accessible; this already stops most of these problems. Also, the way Clojure 1.3 broke code is closer to the way Ruby 1.9 broke code--a change I stated elsewhere in this thread was a non-issue for the Ruby projects I'm involved in--than the way Python 3 broke code, and was in fact even less of an issue than that.)
The article is called "I Am Worried About The Future Of Python" and the specific thread I chose to participate in directly described a way that the Python 3 schism was contributing to the concern (WinRT support). To quote the lead comment for this thread: "I definitely feel like Python qua programming language has become a missed opportunity in many ways".
I then provided my experience, as someone who has been developing for over 20 years in numerous languages (even designing them and teaching them in a university setting), of a unique set of challenges and mistakes that I see Python having run across--a perspective that one reader called "a brilliant if unpopular analysis"--and yet I'm now simply being dragged into the same defensive argument that comes up whenever the 2/3 topic is breached: to turn it into a very personal attack against me and my abilities led by highly inflammatory and insulting wording like "get this into your head", quite despite the fact that I am hardly in the minority with regards to these overall opinions.
Regardless, I am hereby so confused as to what conversation you feel you are participating in that I am just going to bow out: thank you, regardless, for taking the time to respond.
(Oh, I will respond to the semi-unrelated Clojure discussion, as I should probably make certain I don't inadvertently cause them problems: I do not use third-party libraries written in Clojure, as there is really no need given that all of Java is accessible; this already stops most of these problems. Also, the way Clojure 1.3 broke code is closer to the way Ruby 1.9 broke code--a change I stated elsewhere in this thread was a non-issue for the Ruby projects I'm involved in--than the way Python 3 broke code, and was in fact even less of an issue than that.)
I deliberately used the inflammatory phrase "in your head" because you used the phrase "What really seems to happen with Python is that people get it in their heads "developers should not be using this old feature"". The 'people' you are talking about there are the Python core developers. Those are specific people, not abstract entities. I figured that since you used that phrase with them, then I would reverse it, when saying that that wasn't the point.
I've been using Python now for 15+ years. I've read articles about bemoaning the lost opportunities of Python for almost as long. It needs static types otherwise all is lost. It needs tail recursion otherwise all it lost. It needs macros, it needs to get rid of explicit "self", it needs blocks, ... and so on. People thought for a while that Python development was proceeding too fast. There was the language moratorium so others could catch up. Now you say it's going too slow.
If you want to give me specific details about how Python is losing in popularity, please do. You haven't. Nothing I've seen tells me that there's anything more than the usual churn of people moving in between languages, of hipsters talking about the language de jour, of industry people insisting on certain trends. But what you've written describing your experiences with Python's 2-3 transition does not mesh with my own experiences and readings of the experiences of others. How did the change in division cause problems? Why weren't the existing mitigation mechanisms good enough for you?
I've been using Python now for 15+ years. I've read articles about bemoaning the lost opportunities of Python for almost as long. It needs static types otherwise all is lost. It needs tail recursion otherwise all it lost. It needs macros, it needs to get rid of explicit "self", it needs blocks, ... and so on. People thought for a while that Python development was proceeding too fast. There was the language moratorium so others could catch up. Now you say it's going too slow.
If you want to give me specific details about how Python is losing in popularity, please do. You haven't. Nothing I've seen tells me that there's anything more than the usual churn of people moving in between languages, of hipsters talking about the language de jour, of industry people insisting on certain trends. But what you've written describing your experiences with Python's 2-3 transition does not mesh with my own experiences and readings of the experiences of others. How did the change in division cause problems? Why weren't the existing mitigation mechanisms good enough for you?
I truly am going to stick to my word and ignore the rest of your commentary about Python: there is a long thread with a lot of context started by an article that is at least attempting to disagree with your premise; the things you are asking me to explain are thereby all "assumed state" for this tiny sub-part of the conversation, so you can take up your issues with someone up-thread who might feel less insulted by the overall direction of the argument you are making.
However, I will defend my wording, as I think that is unrelated: the phrase "once you get it into your head that" (even with that direct "you", rephrased from "people get the idea into their heads", about others) is a statement about the virility of the idea that someone now believes; in contrast, "get this into your head" is a direct command given to a person used to indicate that they are being dense and thereby are unable (or unwilling) to understand the idea in question.
To make this distinction more clear, you can look at something generally considered positive: "once saurik gets it into his head that something should be built, he builds it" or "people get the idea in their heads that things should be built, and then they actually build them" are both fine; "get this into your head: once you determine something should be built, you should actually build it" is both harsh and patronizing: it is an entirely different concept for the sentence, used as an attack.
However, I will defend my wording, as I think that is unrelated: the phrase "once you get it into your head that" (even with that direct "you", rephrased from "people get the idea into their heads", about others) is a statement about the virility of the idea that someone now believes; in contrast, "get this into your head" is a direct command given to a person used to indicate that they are being dense and thereby are unable (or unwilling) to understand the idea in question.
To make this distinction more clear, you can look at something generally considered positive: "once saurik gets it into his head that something should be built, he builds it" or "people get the idea in their heads that things should be built, and then they actually build them" are both fine; "get this into your head: once you determine something should be built, you should actually build it" is both harsh and patronizing: it is an entirely different concept for the sentence, used as an attack.
To my mind this is a brilliant if unpopular analysis. I would really like to see the ability to import modules "from the past" but it seems extraordinarily difficult to implement that now that 2 and 3 have diverged so much. And one of our problems is exactly what you describe: a large, very-well-tested, 2.X library that we rely on is no longer maintained by anyone. So we'll have to port it ourselves, and surely introduce a bunch of stupid bugs. Grumble.
A saving grace is Python's historical emphasis on unit testing. That makes fore-porting things without horribly breaking them at least plausible. But still painful.
A saving grace is Python's historical emphasis on unit testing. That makes fore-porting things without horribly breaking them at least plausible. But still painful.
> Please realize before disagreeing: I develop compilers, and I have developed virtual machines. I know what kind of effort it takes to have parameterized grammars and internal transformations.
Please be sure that I totally respect your work. Still, while I agree some of your points are right, I believe you're taking a shortcut here:
> For an example of a community that gets this: C. No one develops in K&R C anymore. However, there is still tons of code out there, even code inside of some core projects you use every day, that was written in K&R C and never needed to get serious modifications made.
The syntax evolved, but behind this syntax K&R C behaves in the exact same way, all the way up to the latest C revision. You can't say the same for old vs new classes, which behave in a not so subtly different way, and you can't say that either for the new str/old str, and indeed you propose a different name, which is perfectly legitimate, as they are different things.
The problem is also a vision of scale. I'd say the designed impact of python 3 breaking changes is not for next year, or even the next two years, but for the next 10-15 years. I think the decision came from the realization that there were retrospectively bad or overlooked design choices, and that they needed to be fixed, and thus cut out, now. The most critical things dropped from python 3 are actually stuff carried over from python 1. Python's design and philosophy is around a form of minimalism. The Zen of Python says:
I'd say from anecdotal experience that every single python project I write today works on both 2.7 and 3.2. I sure wish python 3.2 received 2.6's from __future__ import unicode_literals, which would, along with 3.3, remove the biggest part of my headaches. The real problem, as stated, lies in the dependencies, and there's no denying that although you can compile K&R C today, such code was not written in a vacuum and certainly (recursively) relies on a bunch of libs that may or may not work today anymore (because of the code itself, the plaform, or the compiler evolving). It is also in plain sight today with Ruby, where a significant number of historical gems simply don't work anymore in 1.9.x (worse, some appear to work, and silently corrupt stuff, up to a point where it blows up. I'm looking at you mysql, which silently fails to transcode strings, the very situation Python introduced an "upfront error" breaking change).
The point I want to make is that the situation is simply not as clear cut as some want to make it. The short term cost is that we have a rocky transition and that we won't benefit from the new features right now, while the long term benefit will really be seen 10 years down the road. The question you seem to ask is: will Python still be relevant by then? To which none of us has an answer. If not, Python will have paid the price of its 9th zen statement: practicality beats purity.
Now I will return to the pending migration of three real world ruby 1.8 + rails 2.1 apps to ruby 1.9 + rails 3.2 (and hell was the migration of some other app from python 2.6 to 3.1 so much easier).
Please be sure that I totally respect your work. Still, while I agree some of your points are right, I believe you're taking a shortcut here:
> For an example of a community that gets this: C. No one develops in K&R C anymore. However, there is still tons of code out there, even code inside of some core projects you use every day, that was written in K&R C and never needed to get serious modifications made.
The syntax evolved, but behind this syntax K&R C behaves in the exact same way, all the way up to the latest C revision. You can't say the same for old vs new classes, which behave in a not so subtly different way, and you can't say that either for the new str/old str, and indeed you propose a different name, which is perfectly legitimate, as they are different things.
The problem is also a vision of scale. I'd say the designed impact of python 3 breaking changes is not for next year, or even the next two years, but for the next 10-15 years. I think the decision came from the realization that there were retrospectively bad or overlooked design choices, and that they needed to be fixed, and thus cut out, now. The most critical things dropped from python 3 are actually stuff carried over from python 1. Python's design and philosophy is around a form of minimalism. The Zen of Python says:
Now is better than never.
Although never is often better than *right* now.
I'd say from anecdotal experience that every single python project I write today works on both 2.7 and 3.2. I sure wish python 3.2 received 2.6's from __future__ import unicode_literals, which would, along with 3.3, remove the biggest part of my headaches. The real problem, as stated, lies in the dependencies, and there's no denying that although you can compile K&R C today, such code was not written in a vacuum and certainly (recursively) relies on a bunch of libs that may or may not work today anymore (because of the code itself, the plaform, or the compiler evolving). It is also in plain sight today with Ruby, where a significant number of historical gems simply don't work anymore in 1.9.x (worse, some appear to work, and silently corrupt stuff, up to a point where it blows up. I'm looking at you mysql, which silently fails to transcode strings, the very situation Python introduced an "upfront error" breaking change).
The point I want to make is that the situation is simply not as clear cut as some want to make it. The short term cost is that we have a rocky transition and that we won't benefit from the new features right now, while the long term benefit will really be seen 10 years down the road. The question you seem to ask is: will Python still be relevant by then? To which none of us has an answer. If not, Python will have paid the price of its 9th zen statement: practicality beats purity.
Now I will return to the pending migration of three real world ruby 1.8 + rails 2.1 apps to ruby 1.9 + rails 3.2 (and hell was the migration of some other app from python 2.6 to 3.1 so much easier).
> The syntax evolved, but behind this syntax K&R C behaves in the exact same way, all the way up to the latest C revision. You can't say the same for old vs new classes, which behave in a not so subtly different way, and you can't say that either for the new str/old str, ...
A lot of code operates in a regime where it takes strings as input, attempts to find substrings in those strings based on either pure ASCII literals or other strings also given for input, cuts ranges and substrings out of that string, and then generates more strings as output.
This is in the same way that much of that code was designed so it could accept either an str or a unicode, and as far as I can tell that same code should either work quite fine now taking either a bytes or a str; to the extent to which this is not the case, it could easily be made to be the case.
> ... and indeed you propose a different name, which is perfectly legitimate, as they are different things.
FWIW, I didn't "propose" the new name: "bytes" is the new name: that is what the old str type is now called in Python 3, and in fact if you are using Python 2.7 (even Python 2.6) "bytes" and "str" are aliases for each other, as even the people who designed Python believe they are equivalent for the purposes of portable code. Sadly, without keeping around "unicode" (and preferably just deprecating "str" but leaving it as a warning-laden alias for "bytes") that was pointless.
The reason being that the only place you could actually have compatibility between these types was Python 2.6+... except, most "serious Python" has been stuck in Python 2.5 until possibly (I think I see a sea-change) this year. Yes: that is four years during which these transition mechanisms were largely pointless: neither Python 2.6 nor Python 2.7 were actually deployable targets for major and serious libraries.
Personally, I found this surprising: I have been using Python 2.7 since it came out, and I have never had a difficulty upgrading within Python 2.x. However, time and again when I come across a large company using Python and I ask them "what version?" they say "2.5". Meanwhile, both Jython and App Engine were likewise stuck at that level.
That means to "remain relevant" the primary deployment target for most systems needed to be Python 2.5. The idea of supporting Python 3 or even Python 2.6/7 was largely seen as a hopefully-fun diversion at best, and a needless chore at worst.
Thereby, I will argue that what was really needed was actually not Python 2.7: all of the effort put into Python 2.7 with its support for bridging the gap should have been made to Python 3 in reverse. You can't tell me that supporting some of these things as the same time, at least in ways that make the remaining porting discrepancy "realistic", is possible, as Python 2.7 does it: it is obviously possible, as we have an existence proof.
Now, you can totally (and dalke does) tell me they didn't have time to do that to Python 3, but my argument is that all of the effort exerted into Python 2.7 would have been better spent doing the same thing to Python 3, but with the defaults reversed: I believe that the effort would have comparable, and the result would have been to avoid the last four years of hell.
> The short term cost is that we have a rocky transition and that we won't benefit from the new features right now, while the long term benefit will really be seen 10 years down the road. The question you seem to ask is: will Python still be relevant by then?
This "rocky transition", for people who actually use Python to develop libraries or applications, is simply "stagnation".
One of the things I found so weirdly surprising when I finally decided to "bite the bullet and move back to Java-land" was the amazing number of high-quality maintained libraries for relatively new concepts (even ones so new they were "buzzwords"): it was like a kid suddenly being thrown into a candy store.
Whereas I had spent forever, on numerous occasions, trying to piece together semi-working mechanisms out of multiple competing and seemingly now all disowned or disinterested Python libraries (such as for PDF editing), I suddenly had my pick of numerous fully maintained libraries.
This is not the state of the Python ecosystem when I entered, and I argue that the reason this changed is because of the Python 3 split: the result is that the people still sticking with Python during this "rocky transition" are putting themselves at a "practical" disadvantage for the idea of a "pure" language.
> If not, Python will have paid the price of its 9th zen statement: practicality beats purity.
Right: it seems like that tenant was thrown out the window with respect to the changes made in Python 3.
> Now I will return to the pending migration of three real world ruby 1.8 + rails 2.1 apps to ruby 1.9 + rails 3.2 (and hell was the migration of some other app from python 2.6 to 3.1 so much easier).
Is this difficulty caused by Ruby, however, or by Rails? I had had an application that used Sinatra on 1.8, and it took me about an hour to get it fully compatible with Ruby 1.9 (which I did years ago, at the first opportunity).
(Note: my application was handling Unicode data correctly both before and after change: something that would have been noticed immediately as much of the package information I used was in random languages from Russian to Chinese, and I am quite a stickler for having things encoded correctly in my database; yes: I did have to thwack it some on Ruby 1.8 to get it to work correctly, but the result after thwacking I believe required no modifications on Ruby 1.9, a result that I might argue indicates that most people having porting problems are actually fixing bugs, not porting.)
A lot of code operates in a regime where it takes strings as input, attempts to find substrings in those strings based on either pure ASCII literals or other strings also given for input, cuts ranges and substrings out of that string, and then generates more strings as output.
This is in the same way that much of that code was designed so it could accept either an str or a unicode, and as far as I can tell that same code should either work quite fine now taking either a bytes or a str; to the extent to which this is not the case, it could easily be made to be the case.
> ... and indeed you propose a different name, which is perfectly legitimate, as they are different things.
FWIW, I didn't "propose" the new name: "bytes" is the new name: that is what the old str type is now called in Python 3, and in fact if you are using Python 2.7 (even Python 2.6) "bytes" and "str" are aliases for each other, as even the people who designed Python believe they are equivalent for the purposes of portable code. Sadly, without keeping around "unicode" (and preferably just deprecating "str" but leaving it as a warning-laden alias for "bytes") that was pointless.
The reason being that the only place you could actually have compatibility between these types was Python 2.6+... except, most "serious Python" has been stuck in Python 2.5 until possibly (I think I see a sea-change) this year. Yes: that is four years during which these transition mechanisms were largely pointless: neither Python 2.6 nor Python 2.7 were actually deployable targets for major and serious libraries.
Personally, I found this surprising: I have been using Python 2.7 since it came out, and I have never had a difficulty upgrading within Python 2.x. However, time and again when I come across a large company using Python and I ask them "what version?" they say "2.5". Meanwhile, both Jython and App Engine were likewise stuck at that level.
That means to "remain relevant" the primary deployment target for most systems needed to be Python 2.5. The idea of supporting Python 3 or even Python 2.6/7 was largely seen as a hopefully-fun diversion at best, and a needless chore at worst.
Thereby, I will argue that what was really needed was actually not Python 2.7: all of the effort put into Python 2.7 with its support for bridging the gap should have been made to Python 3 in reverse. You can't tell me that supporting some of these things as the same time, at least in ways that make the remaining porting discrepancy "realistic", is possible, as Python 2.7 does it: it is obviously possible, as we have an existence proof.
Now, you can totally (and dalke does) tell me they didn't have time to do that to Python 3, but my argument is that all of the effort exerted into Python 2.7 would have been better spent doing the same thing to Python 3, but with the defaults reversed: I believe that the effort would have comparable, and the result would have been to avoid the last four years of hell.
> The short term cost is that we have a rocky transition and that we won't benefit from the new features right now, while the long term benefit will really be seen 10 years down the road. The question you seem to ask is: will Python still be relevant by then?
This "rocky transition", for people who actually use Python to develop libraries or applications, is simply "stagnation".
One of the things I found so weirdly surprising when I finally decided to "bite the bullet and move back to Java-land" was the amazing number of high-quality maintained libraries for relatively new concepts (even ones so new they were "buzzwords"): it was like a kid suddenly being thrown into a candy store.
Whereas I had spent forever, on numerous occasions, trying to piece together semi-working mechanisms out of multiple competing and seemingly now all disowned or disinterested Python libraries (such as for PDF editing), I suddenly had my pick of numerous fully maintained libraries.
This is not the state of the Python ecosystem when I entered, and I argue that the reason this changed is because of the Python 3 split: the result is that the people still sticking with Python during this "rocky transition" are putting themselves at a "practical" disadvantage for the idea of a "pure" language.
> If not, Python will have paid the price of its 9th zen statement: practicality beats purity.
Right: it seems like that tenant was thrown out the window with respect to the changes made in Python 3.
> Now I will return to the pending migration of three real world ruby 1.8 + rails 2.1 apps to ruby 1.9 + rails 3.2 (and hell was the migration of some other app from python 2.6 to 3.1 so much easier).
Is this difficulty caused by Ruby, however, or by Rails? I had had an application that used Sinatra on 1.8, and it took me about an hour to get it fully compatible with Ruby 1.9 (which I did years ago, at the first opportunity).
(Note: my application was handling Unicode data correctly both before and after change: something that would have been noticed immediately as much of the package information I used was in random languages from Russian to Chinese, and I am quite a stickler for having things encoded correctly in my database; yes: I did have to thwack it some on Ruby 1.8 to get it to work correctly, but the result after thwacking I believe required no modifications on Ruby 1.9, a result that I might argue indicates that most people having porting problems are actually fixing bugs, not porting.)
My friend, we are still a looooong way from the Perl 5/6 debacle! What language doesn't hit a few stumbling blocks?
Perl 6 and Perl 5 can at least be considered separate languages and separate ecosystems: Perl 5 is still under active development, not just for maintenance but for purposes of getting new language features.
It is somewhat confusing that these two languages differ by a number and not by name, but the intention is somewhat clear. In the case of Python, they seriously seem to believe that everyone is going to "upgrade".
It is somewhat confusing that these two languages differ by a number and not by name, but the intention is somewhat clear. In the case of Python, they seriously seem to believe that everyone is going to "upgrade".
The other thing about Perl 5 and Perl 6, is the backwards incompatibility gap is way large. And Perl 6 is designed such that Perl 16 shouldn't be necessary.
You can't really say the same thing about Python. If Python wants to remain in the game, I don't see how they can do it unless they are OK breaking backwards compatibility in another 6 years.
Python broke backwards compatibility for as simple a thing like a print statement. Nobody like to play stupid expensive migration games just because your language designer decided that print statement must be written a different way.
You can't really say the same thing about Python. If Python wants to remain in the game, I don't see how they can do it unless they are OK breaking backwards compatibility in another 6 years.
Python broke backwards compatibility for as simple a thing like a print statement. Nobody like to play stupid expensive migration games just because your language designer decided that print statement must be written a different way.
> Python broke backwards compatibility for as simple a thing like a print statement. Nobody like to play stupid expensive migration games just because your language designer decided that print statement must be written a different way.
That is a silly argument. They didn't break compatibility because they wanted to change the way print is. They changed the print because they already had decided to break compatibility. Ie "lets break compatibility to change print" vs "while we are breaking stuff, lets fix the print too"
That is a silly argument. They didn't break compatibility because they wanted to change the way print is. They changed the print because they already had decided to break compatibility. Ie "lets break compatibility to change print" vs "while we are breaking stuff, lets fix the print too"
The idea of "breaking compatibility" is not really a boolean: it is measured in the scalar unit of "difficulty required to regain compatibility".
In that case I'd say changing print would belong to the "trivial" end of the scale. Print function was backported to Python 2.6, so you can easily write code that is compatible with both. And modifying existing code is so trivial that even an automated tool (2to3) can do it reliably.
Yeah, I think the "no new features in 2.7.1+" has been making Python less exciting to use for the past few years, as libraries have slowly started to support Python 3. I think the future might feel less bleak once Python 3 becomes a better option in deployment.
As for the original article, I don't mind if Python's future isn't everywhere, but I find it sad that modern languages like Go and Rust don't copy more of Python's features (and my top contender for this is actually significant whitespace, because I find it greatly helps readability).
As for the original article, I don't mind if Python's future isn't everywhere, but I find it sad that modern languages like Go and Rust don't copy more of Python's features (and my top contender for this is actually significant whitespace, because I find it greatly helps readability).
> "no new features in 2.7" has been making Python less exciting
Erm... Not exactly. http://docs.python.org/whatsnew/2.7.html
"To help with porting to Python 3, several new features from the Python 3.x series have been included in 2.7"
Erm... Not exactly. http://docs.python.org/whatsnew/2.7.html
"To help with porting to Python 3, several new features from the Python 3.x series have been included in 2.7"
Err, yeah. I mean in 2.7, as in, 2.7.1+. I've updated my post to make that more clear.
Hasn't that generally been the case? That is, Python 2.6.1 "is the first bugfix release of Python 2.6. Python 2.6 is now in bugfix-only mode; no new features are being added." So there's nothing new about 2.7.1 being only a bugfix release.
There will be no python 2.8. Ref: http://www.python.org/dev/peps/pep-0404/
Hmm. I think I misread things. I thought the author was saying that 2.7.x is a problem because 2.7.x are bug fixes-only. I now see I could have read that as there will be no features added, starting with 2.7.
> We see more major titles written in Flash and ActionScript than we see written in Python.
People want to write games in Python (myself included). They really do. The problem is, try to get pyopengl/pyglew/pygame/pyogre/pysdl or whatever running on your development machine. Now try to make it work on five different machines, across Windows/OSX/Linux. Then try to create a reliable distribution scheme for it.
I've tried it. Even the first step is painful, often requiring intimate knowledge of C, autoconf/make/whatever build systems and the system you're targeting, jus tto get you going. It's such a pain I just end up writing stuff in C, and only maybe plug in the python stuff later on, if at all.
Really, the lowest levels like PyOpenGL should have been part of the official Python distribution, just like tkinter, even if they are thin ctypes-like wrappers.
People want to write games in Python (myself included). They really do. The problem is, try to get pyopengl/pyglew/pygame/pyogre/pysdl or whatever running on your development machine. Now try to make it work on five different machines, across Windows/OSX/Linux. Then try to create a reliable distribution scheme for it.
I've tried it. Even the first step is painful, often requiring intimate knowledge of C, autoconf/make/whatever build systems and the system you're targeting, jus tto get you going. It's such a pain I just end up writing stuff in C, and only maybe plug in the python stuff later on, if at all.
Really, the lowest levels like PyOpenGL should have been part of the official Python distribution, just like tkinter, even if they are thin ctypes-like wrappers.
I can't speak for the rest, but pygame is trivial to get running on multiple systems, so I don't know what you're talking about in that regard.
I've heard pretty bad things about pyogre though.
I've heard pretty bad things about pyogre though.
As a counter example, I once had a hard time getting pygame running on OS X. I don't remember exactly what the issue was, it may have had something to do with multiple versions of python installed on my machine, but it was enough of a pain that after a couple of hours trying to figure it out I decided I didn't care enough about checking out pygame to work it out. This might have been the kind of thing that someone more experienced in python would have known how to solve immediately, but for me at the time it was too much.
On the other hand, on other machines it was a breeze to set up.
On the other hand, on other machines it was a breeze to set up.
Just a tip: it's useful to use virtualenv [1] to deal with multiple versions.
[1] http://www.virtualenv.org/en/latest/index.html
[1] http://www.virtualenv.org/en/latest/index.html
pip install pygame fails here today, the same way it failed me a year or so ago.
from [0]:
Pyglet's master branch still uses Carbon, so you have to use a years-old experimental Cocoa branch, which won't be merged because it requires pyobjc[1]. This in turn requires pyobjc, which requires a little trickery to install:
[1] https://groups.google.com/forum/?fromgroups=#!topic/pyglet-u...
from [0]:
brew install sdl sdl_image sdl_mixer sdl_ttf smpeg portmidi
pip install hg+http://bitbucket.org/pygame/pygame
Pyglet's master branch still uses Carbon, so you have to use a years-old experimental Cocoa branch, which won't be merged because it requires pyobjc[1]. This in turn requires pyobjc, which requires a little trickery to install:
export MACOSX_DEPLOYMENT_TARGET=10.6 # else it'll fail at finding some libs, and stubbornly tries to stay in 32-bit land
easy_install pyobjc-core==2.3 # else pyobjc fails to build this by itself
easy_install pyobjc==2.3 # finally
[1] https://groups.google.com/forum/?fromgroups=#!topic/pyglet-u...
Really? Because I couldn't get the Ubuntu package or the one from pip to work. And the last article on HN that mentioned it has the author having to install it from a bundle on the pygame site, which is also what I ended up doing before moving on.
Are you using python 3.2? Pygame has ( or had) issues with it.
Didn't the author mean using python as a scripting language for gameplay with a C game engine for the other stuff? Do you really need all those opengl / ogre / sdl whatevers; is it not possible to just have a python interpreter running in your game engine and only running vanilla Python code?
That's how we've done it before with LUA and other scripting languages in game dev. You don't expose anything low level to the gameplay scripting beyond simple primitives. You certainly don't touch anything to do with OpenGL - even the C++ game code rarely goes that deep.
That's how we've done it before with LUA and other scripting languages in game dev. You don't expose anything low level to the gameplay scripting beyond simple primitives. You certainly don't touch anything to do with OpenGL - even the C++ game code rarely goes that deep.
You can, but I've been told that integrating Python is a lot more involved than integrating Lua. People who've done it mostly seem to complain about (a) the relative complexity of Python's object model, and (b) how obnoxious it is to maintain reference counts efficiently.
I've done both, and neither seemed all that difficult, but then again our scripting requirements were pretty primitive.
I've done both, and neither seemed all that difficult, but then again our scripting requirements were pretty primitive.
> is it not possible to just have a python interpreter running in your game engine and only running vanilla Python code?
Sure, but it means much bigger swaths of C/C++ code and your game app is no longer a python program that imports some extension modules for performance critical tasks or third party lib bindings.
Sure, but it means much bigger swaths of C/C++ code and your game app is no longer a python program that imports some extension modules for performance critical tasks or third party lib bindings.
Yeah, the freely available Python libs may not seem polished enough. [edit: not that I have experience trying to ship multiplatform games with them] But: if you flip it around embedding Python in your C++ framework as a "scripting engine", it's pretty crappy
too compared to a natively Python-driven system. And
since most people aren't starting from scratch it's
not so easy to configure the custom engine as a bunch of Python
extensions either.
I'd really like to see some responses to this, even if incomplete. Is there a way forward here? Even a hunch at a way forward?
I haven't tried it myself, but have you experimented with Panda3d? It's a game engine that supports code written in Python, but it has a much more coherent story for getting set up for development, and for distributing your game when you're done.
Oh goodness. This. I used to work with a friend on a port of a game to Python. PyGame installation was fine - but pygame also had horrendous performance! The library we ended up using was really, really difficult to set up for development.
We briefly had to make our own library for reasonable 2D performance.
We briefly had to make our own library for reasonable 2D performance.
"Python behind the webserver is a powerful tool and one that has enabled a lot of great sites and products and services. Unfortunately, once the content hits the wire, the Python stops."
Not sure if im being ignorant here but surely this is a problem for most server side languages? PHP, Ruby, Go, Perl would all suffer the same problems. Browser vendors only want to have JS client side for obvious reasons, this doesn't just affect python.
Js is clearly doing a fine job at client side programming, should we not be happy with that?
Why are people obsessed about creating a "jack of all trades" language instead of letting languages do what they do best?
Taken from the comments... "I suspect javascript will become like assembly and all languages targeting the browser platform will need to be compiled to javascript."
That sounds like hell to a front-end developer. Its bad enough learning coffeescript or other dialects if a company uses them, but other languages too?
Not sure if im being ignorant here but surely this is a problem for most server side languages? PHP, Ruby, Go, Perl would all suffer the same problems. Browser vendors only want to have JS client side for obvious reasons, this doesn't just affect python.
Js is clearly doing a fine job at client side programming, should we not be happy with that?
Why are people obsessed about creating a "jack of all trades" language instead of letting languages do what they do best?
Taken from the comments... "I suspect javascript will become like assembly and all languages targeting the browser platform will need to be compiled to javascript."
That sounds like hell to a front-end developer. Its bad enough learning coffeescript or other dialects if a company uses them, but other languages too?
That's the issue with this -- if this is actually a problem for Python, then it's a problem for EVERY programming language.
Let's first see what satisfies these problem areas:
Mobile = [ObjectiveC, Java, C (native client)] (and maybe Javascript+HTML if you look at the "compile down"/"webview" solutions)
Browsers = [Javascript] (and _maybe_ C if you say Emscripten is actually a sane solution to problems but I'd argue it fits only a minority of cases)
Games = [ObjectiveC (iPhone games), Java, Lua (scripting/plugins), Flash/ActionScript, C, C++]
No single language fits across all of these (dare I call them) niches. Every single language other than Javascript fails the "Browser" test.
I'd argue that focusing on many of these niches is the wrong way to go. Trying to fight for a spot on the mobile front will be a losing battle as Python will always be a second class citizen or flat out denied. The game development front seems like a confusing goal -- how many devs picked up Lua from the plugin system? Additionally, Python isn't fast enough to be the base nor faster than Lua for the plugin system.
The metric that he says he's optimising for is "adoption". I just feel like he's working backwards and optimising for tiny use cases instead of the general case. Many Java classes at university are being replaced with Python for example, and I'd say that's more important for adoption than any of these areas (other than web).
Let's first see what satisfies these problem areas:
Mobile = [ObjectiveC, Java, C (native client)] (and maybe Javascript+HTML if you look at the "compile down"/"webview" solutions)
Browsers = [Javascript] (and _maybe_ C if you say Emscripten is actually a sane solution to problems but I'd argue it fits only a minority of cases)
Games = [ObjectiveC (iPhone games), Java, Lua (scripting/plugins), Flash/ActionScript, C, C++]
No single language fits across all of these (dare I call them) niches. Every single language other than Javascript fails the "Browser" test.
I'd argue that focusing on many of these niches is the wrong way to go. Trying to fight for a spot on the mobile front will be a losing battle as Python will always be a second class citizen or flat out denied. The game development front seems like a confusing goal -- how many devs picked up Lua from the plugin system? Additionally, Python isn't fast enough to be the base nor faster than Lua for the plugin system.
The metric that he says he's optimising for is "adoption". I just feel like he's working backwards and optimising for tiny use cases instead of the general case. Many Java classes at university are being replaced with Python for example, and I'd say that's more important for adoption than any of these areas (other than web).
Don't forget C# from Unity under games.
The take away here is that since client side web programming can only be javascript, it pigeonholes a large chunk of development effort into a forced language. I can't wait for the day web browsers can leverage multiple DOM aware scripting languages. The fact the JS JIT is already tightly coupled with an html / css parser is already bad enough.
The take away here is that since client side web programming can only be javascript, it pigeonholes a large chunk of development effort into a forced language. I can't wait for the day web browsers can leverage multiple DOM aware scripting languages. The fact the JS JIT is already tightly coupled with an html / css parser is already bad enough.
Fat chance. It's already hellish to properly secure one JIT, a multiple-JIT browser would quickly look like Swiss cheese.
Face it: unless something miraculous happens (like Microsoft, Mozilla, Google and Opera all agreeing on a brand new language), javascript will likely remain the only choice for "in-browser" UI development. Unless the browser gets replaced wholesale, we're screwed like that.
Face it: unless something miraculous happens (like Microsoft, Mozilla, Google and Opera all agreeing on a brand new language), javascript will likely remain the only choice for "in-browser" UI development. Unless the browser gets replaced wholesale, we're screwed like that.
Once Chrome gains enough users, they can choose to include Dartium (their Dart VM) in Chrome and choose to support that.
As a language Dart is not exciting. It doesn't tout fancy monads or functional data structures and so on, but it looks basic, simple and average. Kind of like what Java would be if it was made for the web.
So there is at least on contender out there to replace JS.
Mozilla is working on Rust. A very exciting language that actually has many fancy features, some borrowed from Erlang. Not sure if that will ever make into an in-browser language, but who knows.
As a language Dart is not exciting. It doesn't tout fancy monads or functional data structures and so on, but it looks basic, simple and average. Kind of like what Java would be if it was made for the web.
So there is at least on contender out there to replace JS.
Mozilla is working on Rust. A very exciting language that actually has many fancy features, some borrowed from Erlang. Not sure if that will ever make into an in-browser language, but who knows.
Although I agree in spirit, I took a different design route in Ginger which supports multiple syntaxes and front-ends. By designing a generic syntax tree and defining its mapping into (a tight subset of) XML, I got away from the details of the back-end virtual machine. In fact Ginger has three very different back-ends, ported easily to another system (Poplog), and would be a days work to get it running in Java (badly - maybe a couple of weeks work to get it running well!)
We ought to move from browser languages to browser bytecode VMs. Everybody gets to use their favorite language and we have a single target to secure.
> No single language fits across all of these (dare I call them) niches. Every single language other than Javascript fails the "Browser" test.
there are the compile-the-browser-component-to-javascript options like haxe and opa. haxe is even planning on compiling to mobile platforms.
there are the compile-the-browser-component-to-javascript options like haxe and opa. haxe is even planning on compiling to mobile platforms.
Js is clearly doing A job at client side programming, because there is nothing else available.
I would so, so happily drop Javascript for just about ANYTHING else that works on IE+Chrome+Firefox+Safari.
IMO, Javascript is just awful, and I know I'm not alone with that opinion.
I would so, so happily drop Javascript for just about ANYTHING else that works on IE+Chrome+Firefox+Safari.
IMO, Javascript is just awful, and I know I'm not alone with that opinion.
"Js is clearly doing A job at client side programming, because there is nothing else available."
So Java Applets are forgotten already ... and they had such grand plans! I for one won't miss them at all.
So Java Applets are forgotten already ... and they had such grand plans! I for one won't miss them at all.
Java was never in a similar position to JavaScript. Java applets were never properly implemented as an integrated browser component that you can rely on. For example, you couldn't use Java to manipulate DOM and CSS.
>IMO, Javascript is just awful, and I know I'm not alone with that opinion.
I had that opinion at first, but actually Javascript is a pretty good (and even pretty) language if you stick to the good parts [1]. Having the code automatically checked by JSHint helps a lot.
[1] "JavaScript: The Good Parts" by Douglas Crockford
I had that opinion at first, but actually Javascript is a pretty good (and even pretty) language if you stick to the good parts [1]. Having the code automatically checked by JSHint helps a lot.
[1] "JavaScript: The Good Parts" by Douglas Crockford
I needed to link to this image:
http://anongallery.org/img/2/0/javascript-the-good-parts-the...
http://anongallery.org/img/2/0/javascript-the-good-parts-the...
That sounds like hell to a front-end developer. Its bad enough learning coffeescript or other dialects if a company uses them, but other languages too?
Isn't that like saying that having many server side languages is hell to server-side developers?
And isn't it making JavaScript effectively a jack of all trades? You might want to run code on the browser that is better expressed in a different language. After all, the days of client-side code being just a few value checks and DOM manipulation are beginning to disappear.
Isn't that like saying that having many server side languages is hell to server-side developers?
And isn't it making JavaScript effectively a jack of all trades? You might want to run code on the browser that is better expressed in a different language. After all, the days of client-side code being just a few value checks and DOM manipulation are beginning to disappear.
'Why are people obsessed about creating a "jack of all trades" language instead of letting languages do what they do best?'
I can only speak for myself, but there is something extremely attractive about being able to do all of one project in a single language. A reduction in the overhead of context switches, perhaps? Fewer absent-minded semicolons in my python code? Correct me if I am wrong, but, isn't this a big part of the draw in Node.js?
I can only speak for myself, but there is something extremely attractive about being able to do all of one project in a single language. A reduction in the overhead of context switches, perhaps? Fewer absent-minded semicolons in my python code? Correct me if I am wrong, but, isn't this a big part of the draw in Node.js?
Most of the projects I work on require the use of several languages, and to me it's nice to be able to use the sharpest tool for each job. In a given day I might use one or more of C, C++, Python, sh (which possibly includes bits of sed/awk/etc), and make. In the not-far-distant past I switched between C, perl, python multiple times during the workday. The context switches aren't too jarring -- a stronger statement would be that I think it's easier to context-switch and use appropriate tools than it is to dance around a general purpose tool. E.g. substitution in perl or sed versus any other language.
Your point about sharper tools is absolutely fair and well-taken here. I wonder, though, are there diminishing returns when you have a language like Python that is a jack of so many trades? Is it worth the context switch for a tool that is only very slightly sharper?
It is usually worth the context switch, especially when (a) the project already has several tools in play and/or (b) the alternative is much sharper. A situation that calls for expect, or for sed, for example, is likely to be much more easily solved than with python.
On the other hand, if you're working on a system that is almost exclusively python, it wouldn't make sense to use something only "very slightly sharper". E.g. calling out to perl to do some one-liner that needs 5 lines in python.
On the other hand, if you're working on a system that is almost exclusively python, it wouldn't make sense to use something only "very slightly sharper". E.g. calling out to perl to do some one-liner that needs 5 lines in python.
I know what you mean. Coming from a Python background I first wrote Javascript in a Python-ish way. Now it's the other way around and I put semicolons at the end of the line, parentheses around logic clauses and use the wrong logic operators in my Python code. This because I work on both code bases simultaneously (Javascript on the client, Python on the server)...
I have used regularly Python for backend and JavaScript for frontend at the same time (right now I am mainly using Python), and I never got those kind of cross-language problems...
Curious...
Curious...
"Not sure if im being ignorant here but surely this is a problem for most server side languages? PHP, Ruby, Go, Perl would all suffer the same problems."
Python's main competition in the future will be Dart and ES.Next(the next version of JavaScript)... and maybe even Kotlin which has a JavaScript backend.
"Why are people obsessed about creating a "jack of all trades" language instead of letting languages do what they do best?"
Sometimes these languages do things better than the original languages that had their niche.
Python's main competition in the future will be Dart and ES.Next(the next version of JavaScript)... and maybe even Kotlin which has a JavaScript backend.
"Why are people obsessed about creating a "jack of all trades" language instead of letting languages do what they do best?"
Sometimes these languages do things better than the original languages that had their niche.
Python's main competition in the future will be Dart
Is there any indication that Dart developers want to move Dart outside of the web domain? Everything on their website is all about "HTML 5" and "web apps".
Is there any indication that Dart developers want to move Dart outside of the web domain? Everything on their website is all about "HTML 5" and "web apps".
>Js is clearly doing a fine job at client side programming, should we not be happy with that?
I'm not happy with that. Lots of people want to say that the Web will one day replace native apps and this is precisely one of the reasons I hope that never happens: with a native App I can do the whole thing in one language. With the web I have to deal with HTML, CSS, <server side language > and Javascript for the client side. At the very least I'd like to be able to use <server side language> on the client as well. Why must we all be forced to use Javascript? It's not even a particularly nice language IMO.
>That sounds like hell to a front-end developer. Its bad enough learning coffeescript or other dialects if a company uses them, but other languages too?
What? Right now all languages either use a VM or they compile to assembly. Has that been so bad? If you read server side code you might be required to learn literally any language. Why should the client be different?
My hope is that someone will come out with a VM browser plug in that lets me write in any language I want, compile to to a binary that runs on that VM, and this plug in eventually replaces Javascript as the defacto web language.
Stop holding the browser client side programming environment hostage!
I'm not happy with that. Lots of people want to say that the Web will one day replace native apps and this is precisely one of the reasons I hope that never happens: with a native App I can do the whole thing in one language. With the web I have to deal with HTML, CSS, <server side language > and Javascript for the client side. At the very least I'd like to be able to use <server side language> on the client as well. Why must we all be forced to use Javascript? It's not even a particularly nice language IMO.
>That sounds like hell to a front-end developer. Its bad enough learning coffeescript or other dialects if a company uses them, but other languages too?
What? Right now all languages either use a VM or they compile to assembly. Has that been so bad? If you read server side code you might be required to learn literally any language. Why should the client be different?
My hope is that someone will come out with a VM browser plug in that lets me write in any language I want, compile to to a binary that runs on that VM, and this plug in eventually replaces Javascript as the defacto web language.
Stop holding the browser client side programming environment hostage!
That sounds like hell to a front-end developer. Its bad enough learning coffeescript or other dialects if a company uses them, but other languages too?
As a full stack web developer I have to know multiple languages and constantly learn new ones. Why should front-end be any different?
Ironically, one of the most common accusation I hear when someone speaks out against server-side JS is an accusation of not willing to learn new things. Double standards.
As a full stack web developer I have to know multiple languages and constantly learn new ones. Why should front-end be any different?
Ironically, one of the most common accusation I hear when someone speaks out against server-side JS is an accusation of not willing to learn new things. Double standards.
I agree. Python is very popular for web development (server-side) as well as for GUI/CLI application development. It has attained "critical mass" a long time ago, and won't go anywhere anytime soon. Python has a number of strengths and weaknesses that make it suitable for many applications and not so suitable for many others. But that's ok, it doesn't need to be the one-and-only language to succeed.
I really think PyPy is the future of Python. A faster python with better support for paralellism by leveraging STM. This makes Python suitable to a lot of use-cases where it's currently too slow. What is lacking at this moment is compatibility with a lot of the libraries in the ecosystem (see https://bitbucket.org/pypy/compatibility/wiki/Home), due to limited C-API compatibility (which is non-trivial to say at least due to different memory management and locking semantics). This is serious because a big part of what makes Python so cool is the wide library support.
Yet it only really address part of the problem. AFAIK, right now pypy is a memory ogre that would not fit on a mobile. If someone with Pypy knowledge would enlighten us about if it will ever be possible to run it on a 1 GB mobile phone or a tablet ?
Right now memory usage is pretty bad. But mind that tablets and phones will have more and more memory in the future, while at the same time, very smart people are working at improving PyPy. I'm pretty optimistic in that regard.
After all: If it's possible to get JS JITs to fly on mobile devices, which it is, why not Python? I really see no structural problems.
After all: If it's possible to get JS JITs to fly on mobile devices, which it is, why not Python? I really see no structural problems.
I tend to agree with you, it will happens. But Python is loosing mindshare right now, won't it be too late if we wait to get to the point where both Pypy consume less memory and device have enough memory ? I think that's the point of the article is what can be done now to not be late on the bandwagon and surf on latest trends. We are somewhat talking about platform marketing here, I think.
Where is Python's mindshare going?
IMHO, more or less as stated in the article, webdev went to Golang and Node.js, gamedev to lua and python mobile hardly existed in the first place.
The latest-trend-kids will always be doing their thing. Python will never be as hot to them as when it was new. It isn't really a problem. It is possible that NodeJS, Golang never reach the popularity that Python gained in the first place, because the cool kids will jump the bandwagon again and again for something hotter and newer. It's not where the real work is happening, they're just the loudest.
I see more people around me learning Python every day, because it is a useful language to get stuff done, has excellent bindings for almost every other library, and is pretty stable (ie, the language has been about the same for a long time).
I see more people around me learning Python every day, because it is a useful language to get stuff done, has excellent bindings for almost every other library, and is pretty stable (ie, the language has been about the same for a long time).
I agree, PyPy is looking like the future of Python.
Once it supports third party libraries or things change I believe python will be flying.
I for one am not worried.
I for one am not worried.
Could you clarify what you mean by "third party libraries"? Do you mean libraries written in Python like those [which are pure Python] on http://pypi.python.org/pypi ?
These are not all written in Python. A lot of them are actually C or C++, some are Haskell or Fortran (that's no error, Fortran). Even the ones written in pure Python often ultimately depend on something that's just a wrapper over something in another language. In fact, could be an interesting side project to determine how much of PyPI doesn't work with PyPy...
Yes, I knew that. There was an implicit (now explicit) "written in Python" in my comment above.
(The purpose of my original comment was because PyPy does work with third party libraries, especially if they are pure Python, and so I was asking if these were the sort of libraries that were being referred to.)
(The purpose of my original comment was because PyPy does work with third party libraries, especially if they are pure Python, and so I was asking if these were the sort of libraries that were being referred to.)
BTW I just discovered that there is a project called cppyy, as part of PyPy: http://doc.pypy.org/en/latest/cppyy.html
It looks pretty cool. When it's possible to directly use C/C++ libraries, the raison d'etre for a lot of the third-party bindings that use the C-API disappears.
It's not faster. It's only faster for specific use-case, running the same stuff for long time in a loop. This use-case is a good fit for running webapps, but not small scripts, hooks, mobile or desktop apps that trigger some (relatively) small amount of (different) work randomly (on user's activity).
To be fair, almost all longer running applications fall into the "same stuff for long time in a loop" category. Whether it's a GUI event loop, rendering, scientific computation, or a network server.
Sure, very small scripts and hooks only do one thing one time, but usually those aren't the things that benefit from being heavily optimized in the first place, and could just as well be left interpreted (even better -- as interpreted code is more compact and thus better fits in the cache). The same holds for every other JIT-based language.
Sure, very small scripts and hooks only do one thing one time, but usually those aren't the things that benefit from being heavily optimized in the first place, and could just as well be left interpreted (even better -- as interpreted code is more compact and thus better fits in the cache). The same holds for every other JIT-based language.
Well, I'm actually not sure they do. I'd like very much to get some real-world example and experience to see. But until then, I don't think that clicking the same button >1000 times to make JIT work will be faster in real life.
Overall, PyPy lefts expression as project that "gets fantastic things done" and I'm looking forward using it everywhere I can.
Overall, PyPy lefts expression as project that "gets fantastic things done" and I'm looking forward using it everywhere I can.
Regarding games: I chose lua over python because:
* smaller runtime foot print.
* faster runtime.
* simpler to embed
* the fewer batteries that are included are simpler to embed in your runtime. Python's libraries are often very tricky to embed.
I prefer python to lua, although they are both expressive and powerful languages, however the convenience of python isn't enough to trump the flexibility and speed of lua.
(edit formatting)
* smaller runtime foot print.
* faster runtime.
* simpler to embed
* the fewer batteries that are included are simpler to embed in your runtime. Python's libraries are often very tricky to embed.
I prefer python to lua, although they are both expressive and powerful languages, however the convenience of python isn't enough to trump the flexibility and speed of lua.
(edit formatting)
There is also a lot more experience in the mobile space of using Lua than Python. That means a lot more blog posts and documentation.
Ah yes, thanks for reminding me. This is also very important.
And corona is a pretty nice kit for iOS/Android and is fully supported.
http://www.coronalabs.com/products/corona-sdk/
http://www.coronalabs.com/products/corona-sdk/
I also like Lua. The speed of the virtual machine is awesome. But sadly Lua is still missing Unicode support. This is a big issue that needs to be solved.
> But sadly Lua is still missing Unicode support.
Whenever I hear someone complain about (lack of) Unicode support, my ears prick up. See, Unicode support is a many-headed beast, and almost no languages have very much of it, and most of what people naively think of as Unicode support (length, indexing into "characters", case conversion) doesn't really work when you take into account combining diacritics, ligatures, Turkish I, German S, etc.
I'm not especially familiar with Lua, but it transparently stores and compares UTF-8 strings, and there are even bindings for ICU. So what's missing from "Unicode support"? Script specifiers in regular expressions, perhaps? I'm asking out of genuine curiosity.
Whenever I hear someone complain about (lack of) Unicode support, my ears prick up. See, Unicode support is a many-headed beast, and almost no languages have very much of it, and most of what people naively think of as Unicode support (length, indexing into "characters", case conversion) doesn't really work when you take into account combining diacritics, ligatures, Turkish I, German S, etc.
I'm not especially familiar with Lua, but it transparently stores and compares UTF-8 strings, and there are even bindings for ICU. So what's missing from "Unicode support"? Script specifiers in regular expressions, perhaps? I'm asking out of genuine curiosity.
Those who fail to realize the importance of unicode support is the same group of people think handling strings with \0 terminator is OK.
But no, it's fucking not OK. Lacking basic unicode handling means everyone handles unicode strings in different ways, so various libraries clutter in basic string capabilities. Sometimes this really piss me off.
But no, it's fucking not OK. Lacking basic unicode handling means everyone handles unicode strings in different ways, so various libraries clutter in basic string capabilities. Sometimes this really piss me off.
Um, UTF-8, a valid unicode encoding, handles strings with a null terminator just fine. Those who throw stones, should not live in glass houses.
Proper unicode support would include things like normalizing strings (Unicode has 4 different normal forms!) and testing for fuzzy equivalence. But last time I checked, the usual library for doing those things, libicu, was bigger than the whole Lua interpreter. So I can see why there isn't a lot of enthusiasm, especially if there isn't a real use case.
Proper unicode support would include things like normalizing strings (Unicode has 4 different normal forms!) and testing for fuzzy equivalence. But last time I checked, the usual library for doing those things, libicu, was bigger than the whole Lua interpreter. So I can see why there isn't a lot of enthusiasm, especially if there isn't a real use case.
yes, packing icu with every lua distribution or standalone app is bad, and we don't even need to think about OS's Unicode capabilities. So every lang deserves to be suck at unicode handling. Because, you know, ICU is big.
> but it transparently stores and compares UTF-8 strings
Thanks for this good news! The last time I tried Lua it didn't work. UTF-8 is ok, full Unicode is not necessary.
Thanks for this good news! The last time I tried Lua it didn't work. UTF-8 is ok, full Unicode is not necessary.
Lua, a programming language I think might appeal to Pythonistas, is in a solid position to profit from the compile-to-JavaScript fad. I did some tests with mherkender's lua.js[1] a while back and Lua translated to JavaScript was only taking around 40% more time (I forget the exact numbers) to run the horrible benchmarks I wrote. There's still low hanging fruit to improve those numbers. Lua is a beautiful language. In addition, it's the language with the best chance at making it into a browser engine. It's lightweight - the compiled binary is around 120KB.
[1] https://github.com/mherkender/lua.js
[1] https://github.com/mherkender/lua.js
I'm not sure that Lua is going to appeal so strongly to Python programmers. It's wordy and its design makes opposite choices from Python's; vide global vs. local, for example. I think the brevity and safe assumptions of Python are a lot of what people value in it.
Thats if you only focus on syntactic issues like that. If you see how the languages work they are actually much more similar (both have generators, operator overloading, lexical scope, etc...)
Using any syntax, "local unless you specify global" and "global unless you specify local" are different in an important way. And syntax is important to most programmers; there are dozens of languages that provided the semantic equivalent of Python before it existed, but haven't matched its popularity. Python's practical syntax is much of the reason.
> Lua [is] the language with the best chance at making it into a browser engine
For better or for worse, I think there is pretty much 0 chance of Lua or for that matter Python showing up natively in browsers. There are too many technical and political things in the way.
But we already have good tools for compiling both of those languages into JavaScript. If for example the Python community made JavaScript a priority to compile to, we could make it run very well and integrate nicely with the browser environment.
For better or for worse, I think there is pretty much 0 chance of Lua or for that matter Python showing up natively in browsers. There are too many technical and political things in the way.
But we already have good tools for compiling both of those languages into JavaScript. If for example the Python community made JavaScript a priority to compile to, we could make it run very well and integrate nicely with the browser environment.
"too many ..."
Not if you write your own browser.
Not if you write your own browser.
Why not coffeescript then? It seems to be have good momentum behind it.
Shedskin might be one solution. From the shedskin forum[1]:
"
I've built and run shedskin apps for the iPhone - it works great actually.
It required commenting a few things out, and swapping in the boehm gc for iOS port.
Of course, no native ui widgets available - but I used phonegap to do the ui in html5 and it called shedskin c++ for all the actual app logic. Phonegap supports connecting html5 -> native c++ via a plugin architecture. Works wonderfully.
High powered, efficient apps on the iPhone via python is a bit of paradise compared to apples own obj-c, I must say. Huge potential for shedskin adoption there if someone packaged things up this way for the general public..."
[1] http://groups.google.com/group/shedskin-discuss/browse_threa...
It required commenting a few things out, and swapping in the boehm gc for iOS port.
Of course, no native ui widgets available - but I used phonegap to do the ui in html5 and it called shedskin c++ for all the actual app logic. Phonegap supports connecting html5 -> native c++ via a plugin architecture. Works wonderfully.
High powered, efficient apps on the iPhone via python is a bit of paradise compared to apples own obj-c, I must say. Huge potential for shedskin adoption there if someone packaged things up this way for the general public..."
[1] http://groups.google.com/group/shedskin-discuss/browse_threa...
I recognize that most of the response I'll probably get from this post amounts to, "You're complaining about silly things. Python doesn't do that, it isn't meant to. Stop putting a round peg in a square hole and complaining when it doesn't work."
If you agree with the above quote, you are committing a Texas Sharpshooter Fallacy. We're not using Python for that, because the interpreter has a significant startup time, because Python performance is not stellar, etc. But it could be different.
I'm a novice programmer without commercial experience, but the statements in bold ring true to me: - Python is Expensive On Mobile - Python is Without a Door On Browsers - Python has Failed for Game Development
If you agree with the above quote, you are committing a Texas Sharpshooter Fallacy. We're not using Python for that, because the interpreter has a significant startup time, because Python performance is not stellar, etc. But it could be different.
I'm a novice programmer without commercial experience, but the statements in bold ring true to me: - Python is Expensive On Mobile - Python is Without a Door On Browsers - Python has Failed for Game Development
As a PHP developer slithering away from PHP at great speed on the back of Python, I am excited about its future.
Yes, I would love to be able to use Python for games and mobile development too, but I do not expect to be able to use it for these things, just as I do not expect to be able to build web apps with Objective-C (even though some do).
For me, the power, elegance, philosophy, and community that sustain Python are enough to make it a worthwhile choice in a finite but important number of domains.
Yes, I would love to be able to use Python for games and mobile development too, but I do not expect to be able to use it for these things, just as I do not expect to be able to build web apps with Objective-C (even though some do).
For me, the power, elegance, philosophy, and community that sustain Python are enough to make it a worthwhile choice in a finite but important number of domains.
Same. I cut my teeth on PHP but have recently started working in Python and like it.
PHP is nice because you can throw it on any LAMP stack and it's interpreted, but Python runs much smoother for heavy data lifting.
PHP is nice because you can throw it on any LAMP stack and it's interpreted, but Python runs much smoother for heavy data lifting.
This is like writing an article in 2003 saying "I'm worried about the future of PHP". Even if you're right and Python is doomed, so what? You'll have another good reason to broaden your resume and become a generalist engineer.
In 2003 PHP was already the most popular web dev language and web dev was where the action was and the transition to PHP4 from PHP3 was pretty smooth. This article points out that he's got code stuck on Python 2.x, Python is not doing well on the current hotmess (mobile) and it's not now and never has been as popular as PHP. How is this similar?
You're taking things too literally. I took PHP as a language that was very popular for web apps in the past, and much less so nowadays. PHP's popularity for the web in 2003 is not dissimilar to Python's popularity for the web in 2012.
Anyone predicting in 2003 that PHP would become less popular and/or suitable for the web would've turned out to be right. Yet, I bet anybody who might've made such a prediction just learned a new language (maybe even Python) and is still enjoying creating great software just like back then.
Anyone predicting in 2003 that PHP would become less popular and/or suitable for the web would've turned out to be right. Yet, I bet anybody who might've made such a prediction just learned a new language (maybe even Python) and is still enjoying creating great software just like back then.
He forgets about concurrency. That's a major point of weakness for the future of Python (even though no one will admit it).
Have you tried using PyPy and gevent? In a well-designed benchmark[1], it outperforms Node.js. That means it's at least competitive when it comes to concurrency... right? The GIL is not a big deal because shared state concurrency is a fundamentally broken model.
[1] http://mrjoes.github.com/2011/12/15/sockjs-bench.html
[1] http://mrjoes.github.com/2011/12/15/sockjs-bench.html
The GIL is not a big deal because shared state concurrency is a fundamentally broken model.
This depends on the problem domain. A lot of the code I write is limited by memory bandwidth. The number of outstanding memory requests is limited by hardware, so saturating the memory bandwidth, especially when many active memory streams are needed, requires several cores to participate. A particularly useful approach now is for threads running on those cores sharing a particular cache level/prefetch unit to perform software "buddy prefetch" while working together on a traversal. The threads are weakly synchronized by memory dependencies, sharing both cache and bandwidth.
If you remove shared state, the threads each need their own ghost region and cannot share cache and bandwidth. I avoid shared state, especially shared mutable state, whenever possible, but there are still plenty of cases where it makes sense, especially at cache and NUMA domain granularity.
This depends on the problem domain. A lot of the code I write is limited by memory bandwidth. The number of outstanding memory requests is limited by hardware, so saturating the memory bandwidth, especially when many active memory streams are needed, requires several cores to participate. A particularly useful approach now is for threads running on those cores sharing a particular cache level/prefetch unit to perform software "buddy prefetch" while working together on a traversal. The threads are weakly synchronized by memory dependencies, sharing both cache and bandwidth.
If you remove shared state, the threads each need their own ghost region and cannot share cache and bandwidth. I avoid shared state, especially shared mutable state, whenever possible, but there are still plenty of cases where it makes sense, especially at cache and NUMA domain granularity.
If your code is limited by memory bandwidth: Why don't you use a language, which gives you more control about memory? Why do you even parallelize?
1. I don't use Python for this task, but libraries like numpy give you ready access to unboxed arrays. It's becoming common in scientific codes to glue together "dumb" numeric components (written in C or Fortran) using Python. Threading granularity is limited in this case due to the GIL, to the point where either "smarter" code must be pushed into the compiled language. To keep the "smart" code in Python, many projects end up using only MPI for parallelism. This was fine until recently, but with modern memory hierarchies and proliferation of cores within a node, it gives up enough performance to be an issue.
2. As I said above, you need to use multiple cores per memory bus to utilize the hardware bandwidth because there is a limited number of outstanding memory requests per core (or hardware thread). Remember that the max bandwidth realized by your application is bounded above by
2. As I said above, you need to use multiple cores per memory bus to utilize the hardware bandwidth because there is a limited number of outstanding memory requests per core (or hardware thread). Remember that the max bandwidth realized by your application is bounded above by
num_pending_requests * payload_per_request / latency
I just hope that by well-designed benchmark, you don't mean tailored-to-fit.
Node.js is definitely not where I would set the bar for concurrency..
[deleted]
Why is he forgetting about concurrency? There seem to be plenty of tools for managing concurrency right now in Python, and they are working fine for me.
What languages are you considering that have a better story here? Note that better story has to mean more than "syntax-level support" -- I run highly concurrent services in Python right now using Twisted without language level support, and it's not always obvious in which ways language level support would make things nicer in ways that aren't already implemented (e.g generators + @inlineCallbacks).
What languages are you considering that have a better story here? Note that better story has to mean more than "syntax-level support" -- I run highly concurrent services in Python right now using Twisted without language level support, and it's not always obvious in which ways language level support would make things nicer in ways that aren't already implemented (e.g generators + @inlineCallbacks).
1. You might like gevent.
2. You can't parallelize computation if it's written in Python. (Yeah, yeah, concurrency is different from parallelism, but there is a lot of overlap.) Even if it's written in a different language, the granularity is constrained due to the GIL.
2. You can't parallelize computation if it's written in Python. (Yeah, yeah, concurrency is different from parallelism, but there is a lot of overlap.) Even if it's written in a different language, the granularity is constrained due to the GIL.
1. I don't, but that's an entirely different story.
2. Sure I can :) Usually this means deferToThreading with things that release the GIL, sometimes it means multiple processes, both of which have quite good tools in Python. Not that they can't afford to be better, but I've never thought "man, the GIL is really holding me back now" -- despite having dealt with projects that are almost entirely about heavy computation.
what are you talking about? everybody admits it but it's not an easy problem, otherwise it'd be solved by now. multiprocessing module helps a bit in scenarios where it makes sense to use multiple processes instead of threads for cpu-bound stuff; io-bound problems don't suffer from GIL that much.
Most of the problems look like Lisp problems 20 years ago. Maybe Python is not the best for mobile or for games, but... so what? It's great for some things, and if it excels in those, why does it need to be perfect for everything?
Because else you end like this Lisp of "20 years ago" ended up: used in some niches, largely forgotten in the main.
For languages, number of programmers translates to: higher quality and number of libs, better tested, more work on the efficiency, compiler, more companies built around the ecosystem, more tools, more books, more tutorials, more open source projects in and with it, more bugfixes, new APIs with support for the language, new bindings etc.
It doesn't have to be "perfect for everything", but it has to be good in the kind of things that interest the most people people now. Scientific computing ain't it.
Much better to use a bad language with 100,000 programmers than a good one with 1,000, as people reluctant of JS in the past have found out.
For languages, number of programmers translates to: higher quality and number of libs, better tested, more work on the efficiency, compiler, more companies built around the ecosystem, more tools, more books, more tutorials, more open source projects in and with it, more bugfixes, new APIs with support for the language, new bindings etc.
It doesn't have to be "perfect for everything", but it has to be good in the kind of things that interest the most people people now. Scientific computing ain't it.
Much better to use a bad language with 100,000 programmers than a good one with 1,000, as people reluctant of JS in the past have found out.
I feel this is kind of what happens with php, it isn't the best language, but for someone new in server-side webdev there is plenty of info around the web to solve most problems
So I can't say I'm worried much.
Python strikes a very good balance between rapid development prototyping and something that is sustainable, and has an excellent level of readability that makes it outstanding for gathering patches from even non-professional programmers.
Most of the interesting parts of computing now cluster around web applications and web services, where the action happens on the server and Python is still reasonably well suited -- and in the servers behind them, where it's quite critical in Linux distributions. I write a ton of software for systems administrators and can't really see using anything else if I wanted the same contributor rate.
Sure, it doesn't run in the browser, but I can't see myself pining for the return of Java applets either. It all comes down to what types of applications you are writing.
If I was doing HFT, I'd clearly want something statically typed, fast, and functional. Those same properties are things I don't want in other applications. It's pretty much a screwdriver vs carburetor type of problem.
Yes, I'd love to see more investment in the runtime -- but I'm also reasonably fine with where it's at.
Python strikes a very good balance between rapid development prototyping and something that is sustainable, and has an excellent level of readability that makes it outstanding for gathering patches from even non-professional programmers.
Most of the interesting parts of computing now cluster around web applications and web services, where the action happens on the server and Python is still reasonably well suited -- and in the servers behind them, where it's quite critical in Linux distributions. I write a ton of software for systems administrators and can't really see using anything else if I wanted the same contributor rate.
Sure, it doesn't run in the browser, but I can't see myself pining for the return of Java applets either. It all comes down to what types of applications you are writing.
If I was doing HFT, I'd clearly want something statically typed, fast, and functional. Those same properties are things I don't want in other applications. It's pretty much a screwdriver vs carburetor type of problem.
Yes, I'd love to see more investment in the runtime -- but I'm also reasonably fine with where it's at.
This is a good post and the comments are equally good. Here's the deal. Python nation isn't doing anything new here. Other languages have caused the same soul searching, think of C, Java or Delphi (of bad example). The point is that once a language grows up, and yes it can take takes ten years, it's a natural progression.
I've only been using Python for a few years and now I don't know how I managed to get anything done before. Python as a solid base and excels at certain things. Move on. Use the tool that fits.
As for the mobile hardware being low on power and battery life. Give it time. My computer 12 years ago had a difficult time doing anything when converting video. Now, I can play games while I convert a video and it uses less power/puts out less heat.
Patience.
I've only been using Python for a few years and now I don't know how I managed to get anything done before. Python as a solid base and excels at certain things. Move on. Use the tool that fits.
As for the mobile hardware being low on power and battery life. Give it time. My computer 12 years ago had a difficult time doing anything when converting video. Now, I can play games while I convert a video and it uses less power/puts out less heat.
Patience.
So, what should we be using instead NOW? It's sort of frustrating reading these types of articles. I mean should I not be using python for my web apps anymore? Since we shouldn't be using python anymore, what should i use in the mean time? no suggestion? guess i'll sit here twiddling my thumbs until the next big thing hits hacker news.
Ironic that one of the things that got me hooked into programming and python was PyS60. I could write programs on my phone and run them. That was awesome. This was about 8 years ago on Nokia symbian phones.
Take a look at Kivy. Write code in Python and run it on Android and iOS. Building the dev environments for those platforms is still a pain, but once those are set it, it's a snap. Also, there's an online build server available for Android at no cost.
Main drawback is a slow first-time start-up time as the package files are unpacked. Subsequent start-ups are fine in my experience. Once a kivy program is started, it runs like a charm on modern hardware.
I'm building a scaffolding for productivity apps in Kivy here: https://github.com/esbullington/vite-vite
You can try out the (very alpha quality) Android app build with the scaffolding here: https://github.com/esbullington/vite-vite/vitevite-0.1-debug...
I should have some more time to work on this next week, at which point I'll be cleaning up the code, adding more documentation, and adding a few features. Suggestions and pull requests are welcome.
Main drawback is a slow first-time start-up time as the package files are unpacked. Subsequent start-ups are fine in my experience. Once a kivy program is started, it runs like a charm on modern hardware.
I'm building a scaffolding for productivity apps in Kivy here: https://github.com/esbullington/vite-vite
You can try out the (very alpha quality) Android app build with the scaffolding here: https://github.com/esbullington/vite-vite/vitevite-0.1-debug...
I should have some more time to work on this next week, at which point I'll be cleaning up the code, adding more documentation, and adding a few features. Suggestions and pull requests are welcome.
We see some games written in Flash and ActionScript, but not AAA titles like Eve and Civ 4. How many general-purpose languages get used to write such titles? I can only think of C, C++... yep, that's it.
Is the author's point that we're moving away from "big" games and towards less complex, "casual" games like are popular on mobile, and the latter aren't using python?
Is the author's point that we're moving away from "big" games and towards less complex, "casual" games like are popular on mobile, and the latter aren't using python?
Every game that uses Scaleform (that's a lot of them) uses Actionscript.
Here's a list of games--many of them AAA titles--using Lua: http://en.wikipedia.org/wiki/Category:Lua-scripted_video_gam...
Here's a list of games--many of them AAA titles--using Lua: http://en.wikipedia.org/wiki/Category:Lua-scripted_video_gam...
Scaleform is just for the menus and stuff though isn't it? That's not quite the same as game logic.
[deleted](2)
Python does not typically end up in a video game's main code base. However, to say it failed is to have a pretty limited view of game development. Art asset creation often requires customized tools within software packages like Blender or Maya. Python is doing just fine within it's part of the development pipeline.
I'm a little confused by the first point. How is Objective-C not a dynamic language? Is he talking about something other than dynamic dispatch? Is there some reason other than time that prevents an implementation of Python to mirror what was done with Objective-C?
Python is interpreted, but Objective-C is compiled. That is, a Python program is executed through the Python interpreter, yet an Objective-C program runs natively.
Although he may indeed be confused about "dynamic," since dynamic dispatch has nothing to do with the above, and is supported by all OO languages.
Although he may indeed be confused about "dynamic," since dynamic dispatch has nothing to do with the above, and is supported by all OO languages.
Python is interpreted, but Objective-C is compiled.
There are plenty of lisp compilers out there, but people still consider lisp a dynamic language.
There are plenty of lisp compilers out there, but people still consider lisp a dynamic language.
Again, the author's use of "dynamic" is, I think, confused. I tried to suss out what difference he was actually thinking about, and interpreted versus compiled was the biggest one to me.
Compilation does not necessarily need to remove the dynamism. Objective-C is generally considered a dynamic language, though I get the feeling that many think it is just another C++ with different syntax, which muddies the waters, so to speak.
A quote from Apple themselves:
"Compared to other object-oriented languages based on C, Objective-C is very dynamic. The compiler preserves a great deal of information about the objects themselves for use at runtime. Decisions that otherwise might be made at compile time can be postponed until the program is running. Dynamism gives Objective-C programs unusual flexibility and power."
https://developer.apple.com/library/mac/documentation/Cocoa/...
A quote from Apple themselves:
"Compared to other object-oriented languages based on C, Objective-C is very dynamic. The compiler preserves a great deal of information about the objects themselves for use at runtime. Decisions that otherwise might be made at compile time can be postponed until the program is running. Dynamism gives Objective-C programs unusual flexibility and power."
https://developer.apple.com/library/mac/documentation/Cocoa/...
This is where I'm really not clear. What makes Python harder to compile than Smalltalk (which had some native compilers - Smalltalk/X) or Objective-C?
Well nobody said it would be harder to compile. However the fact is that there is not a compiler for Python, so unless someone writes one that is a downside. Also, the semantics of Python would likely not lead to efficient compiled code anyway, when compared to something like C, Java, or even Haskell - static languages.
The corners of the language make it difficult to benefit from compilation. Per the language, things like the internals of an instance of a class can be manipulated at runtime, so the compiled output ends up needing to support the entire dynamic runtime.
Cython and Nuitka (among others) do this to varying degrees.
Cython and Nuitka (among others) do this to varying degrees.
Didn't Smalltalk basically invent the idea of being able to open up objects at runtime? Even Objective-C, with its strong Smalltalk ties, allows for runtime modification.
Any language with eval is probably going to, by default, be interpreted. You can compile a language with eval, but it means you'll need to stick the compiler into every binary with a program that calls eval.
Common Lisp allows all sorts of internal runtime manipulation and is usually compiled to machine code. :-)
And here I was hoping for some kind of thesis on the woeful state of affairs surrounding the fact they've had 2 major versions competing for developers attention, the with "older" fork being the more the widely supported one.
Every language deals with this until about x.3 of the newer version.
Not every language has such a broad chasm between two versions of the language. In fact, I can't really name one. Maybe ActionScript?
Perl6 v. Perl5. Visual Basic .NET vs. VB6. ANSI C vs. K&R C.
Looking now, "Appendix A of the Fortran 77 standard lists 24 things that are not backward compatible in moving from f66 and f77."
Please tell me how the chasm between Python 2.7 and Python 3.3 is significantly broader than the chasm between the aforementioned languages.
Looking now, "Appendix A of the Fortran 77 standard lists 24 things that are not backward compatible in moving from f66 and f77."
Please tell me how the chasm between Python 2.7 and Python 3.3 is significantly broader than the chasm between the aforementioned languages.
Perl 5 and Perl 6 are completely different languages. The same can be said of VB and VB.NET.
There is a difference between a language rewrite and changing just enough of a language that it might have well been a rewrite.
There is a difference between a language rewrite and changing just enough of a language that it might have well been a rewrite.
I would go so far as to say VB.NET vs VB6 is the same as comparing any flavor of C++ to C#. It doesn't really make a lot of sense, even though they share the same pedigree.
VB.NET is effectively a different language entirely. It's programming .NET with VB-like syntax, not the VB language running on .NET (in my mind, anyways)
VB.NET is effectively a different language entirely. It's programming .NET with VB-like syntax, not the VB language running on .NET (in my mind, anyways)
Ahh, but the goal is to find another language with "such a broad chasm between two versions of the language." It seems I can't win if people decided that my examples are so far apart that they are no longer two versions of the same language. ;)
What about Old S v.s New S? S v.s S4? S vs. R?
What about D1 and D2 of the D programming language?
Classic awk vs. nawk?
Honestly, I could go on. I think the person I'm responding to really doesn't know much about programming language histories.
What about Old S v.s New S? S v.s S4? S vs. R?
What about D1 and D2 of the D programming language?
Classic awk vs. nawk?
Honestly, I could go on. I think the person I'm responding to really doesn't know much about programming language histories.
Don't worry about the future of a tool. They just come and go. As a developer worry about the problems, quality problems you would like to solve. Think about 'whats in it for you'.
The inevitable nature of changing requirements in programming mean, there is always going to be demands for new changes and new features in a programming language. Changes in Syntax and excess syntactical sugar many times come only at the expense of breaking backwards compatibility. What you are seeing now is a saturation with Python. Python is good, but people now want more. I bet you unless Python is ready for major backwards incompatible changes in another 5-6 years they are going to lose this battle against other languages. NodeJS, Go they are all going to eat Python's lunch. What you will see now is cool stuff getting built in some language like Go and will go viral every 15 days. People who had originally no interest will learn just because its getting famous. Architects who just want to sound different and distinct will use it, Slowly but sooner or later there will be job demands for Go. This is inevitable and going to happen. Suddenly people will find every reason under the sun to hate python and love go.
Python will increasingly find itself in the same situation Perl was some years back. And its fans will have to face the same trolling.
Its just your usual technology cycles. By the way I guess its time to start learning Go.
The inevitable nature of changing requirements in programming mean, there is always going to be demands for new changes and new features in a programming language. Changes in Syntax and excess syntactical sugar many times come only at the expense of breaking backwards compatibility. What you are seeing now is a saturation with Python. Python is good, but people now want more. I bet you unless Python is ready for major backwards incompatible changes in another 5-6 years they are going to lose this battle against other languages. NodeJS, Go they are all going to eat Python's lunch. What you will see now is cool stuff getting built in some language like Go and will go viral every 15 days. People who had originally no interest will learn just because its getting famous. Architects who just want to sound different and distinct will use it, Slowly but sooner or later there will be job demands for Go. This is inevitable and going to happen. Suddenly people will find every reason under the sun to hate python and love go.
Python will increasingly find itself in the same situation Perl was some years back. And its fans will have to face the same trolling.
Its just your usual technology cycles. By the way I guess its time to start learning Go.
Hmm. I still see many people griping about Python 3 incompatibility, so here is my comment.
If you have some code that you would like to have working under Python 3, check out a little library called "six". With it, it is simple to maintain a single codebase that works with both Python versions (no translations necessary, forget the 2to3 tool).
For example, the Pyramid web framework (and many related libraries) have been successfully using this approach. This way one can support Python 2.6, 2.7 and 3.2+.
Together with "from future" imports (for Python 2.6 and 2.7), this is easy to understand, though "upgrading" the code may still take time.
At the top of every module of mine I have this:
from __future__ import (absolute_import, division, print_function, unicode_literals)
If you have some code that you would like to have working under Python 3, check out a little library called "six". With it, it is simple to maintain a single codebase that works with both Python versions (no translations necessary, forget the 2to3 tool).
For example, the Pyramid web framework (and many related libraries) have been successfully using this approach. This way one can support Python 2.6, 2.7 and 3.2+.
Together with "from future" imports (for Python 2.6 and 2.7), this is easy to understand, though "upgrading" the code may still take time.
At the top of every module of mine I have this:
from __future__ import (absolute_import, division, print_function, unicode_literals)
Link to syx library: http://packages.python.org/six/
This is just an old rant that has been heard before from many language people, Lisp community included, and the author seems to know it but also refuses to get along with that and is upset because that square peg really, really can't be banged into a round hole.
Python has been in decline for years, maybe 5-6 years now. Python3 definitely cemented a lot the current downward angle. Python isn't out and possibly never will be, but its design has gradually shifted away from the hacker community. And that means the momentum will consequently shift into other languages and environments. And that's fine. Each language will gather the following it deserves, in the ever-changing environment.
Python has been in decline for years, maybe 5-6 years now. Python3 definitely cemented a lot the current downward angle. Python isn't out and possibly never will be, but its design has gradually shifted away from the hacker community. And that means the momentum will consequently shift into other languages and environments. And that's fine. Each language will gather the following it deserves, in the ever-changing environment.
One should not focus in a single programming language, as such the article looks like a developer's cry to use his favorite language everywhere.
Just make use of the best tool for the job. In some cases that tool is not Python, as simple as that.
Just make use of the best tool for the job. In some cases that tool is not Python, as simple as that.
I also built my first startup in python. It was a technical success (and a financial failure) but using it imply a few things :
* good coders. ( bad coders can do much more damage. )
* you need to use cython (and maybe numpy).
* memory profiling is hard
* you need to search pypi alot, there is likely something there to help you.
* windows builds of extensions can be tricky.
I am also concerned about its future, the community seems in a "I know better than you" attitude and I don't see anything major coming, except pypy.
* good coders. ( bad coders can do much more damage. )
* you need to use cython (and maybe numpy).
* memory profiling is hard
* you need to search pypi alot, there is likely something there to help you.
* windows builds of extensions can be tricky.
I am also concerned about its future, the community seems in a "I know better than you" attitude and I don't see anything major coming, except pypy.
There are some innovative ideas that may help "ease" over to python-on-mobile... One of them being pyBead: http://sourceforge.net/projects/pybead/?source=directory
Another would be Muntjac...
The article didn't mention Python's availability in China. Their website download page (http://www.python.org/download) has been blocked by the Firewall since late 2009.
After loking for an explanation:
"http://www.python.org/ftp could bypass GFW to download it. Because of version 2.6.4, the sensitive number 'June 4' to government, so the GFW block the download page."
according to wpopenid on http://posted-stuff.blogspot.hk/2010/07/downloading-python-f...
"http://www.python.org/ftp could bypass GFW to download it. Because of version 2.6.4, the sensitive number 'June 4' to government, so the GFW block the download page."
according to wpopenid on http://posted-stuff.blogspot.hk/2010/07/downloading-python-f...
Thanks, that "June 4" reference could be the reason, but I'd think too many webpages would be blocked if it were. (Of course, I had to look at the .in version of that blogspot page as HK's version, like many others, is blocked in the mainland.)
The FTP site works for me. I visit Hong Kong often enough so not having access to the latest internet stuff isn't usually a problem for very long.
The FTP site works for me. I visit Hong Kong often enough so not having access to the latest internet stuff isn't usually a problem for very long.
Don't you worry about the future of Python, let me worry about blank! - Guido
Incase someone doesn't get this: http://www.imdb.com/title/tt0584440/quotes?qt=qt0361067
I never took Python very seriously because of its shitty documentation.
I want a Python environment running in Chrome NaCL.
Agreed! The constant focus on browser security means that this kind of thing is avoided out of hand even when security is not an issue (for internal deployments for example).
I blogged about that: http://williamedwardscoder.tumblr.com/post/14127327004/googl...
I am really arguing the opposite point. There are lots of situations, particularly in business where you want to be able to interact with the file system and OS. Currently your options are very limited if you want to use a browser as a UI. How do you add a "send as attachment using outlook" button in a web page? Native client does not help with this due to the sandboxing.
In spite of the Elop shenanigans at Nokia, Qt is very healthy, and Qt5 has even been demoed on the Raspberry Pi.
Pyside is now totally integrated and mature. Please take a look.
http://qt-project.org/wiki/PySide-Tutorials-by-Experience-Le...
http://doc.qt.digia.com/4.7-snapshot/gettingstartedqml.html
http://qt-project.org/wiki/PySide-and-QML-Playground
http://qt-project.org/wiki/PySide-Tutorials-by-Experience-Le...
http://doc.qt.digia.com/4.7-snapshot/gettingstartedqml.html
http://qt-project.org/wiki/PySide-and-QML-Playground
There is a Door on Browsers for Python right here:
http://pyjs.org/examples/
https://github.com/pyjs/pyjs/wiki/GettingStarted
Needs more developers... (Hint)
http://pyjs.org/examples/
https://github.com/pyjs/pyjs/wiki/GettingStarted
Needs more developers... (Hint)
For web dev (not game dev) what is Python in danger of losing to? Rails?
IMO the largest competitor for new developers would be Node.js, and for existing developers would be Go
Haven't really been following Go at all. Are there any companies (besides Google) that are using Go on the web?
I don't know about companies using it, but here's the django equivilent... totally confident it's a production ready replacement for django, RoR, etc.
http://www.getwebgo.com/tutorial
http://www.getwebgo.com/tutorial
Given that it has no template language and (seemingly) no database mapper, much less support for caching, user account, etc., I'm confident that it's not in the same space as Django or RoR. For example, how do I get it to talk with a Postgres database, and do LDAP authentication?
> Given that it has no template language
Ahem...
http://golang.org/pkg/html/template/
It doesn't have its own equivalent of RoR or Django yet because most of the batteries needed for web development are built-in.
Ahem...
http://golang.org/pkg/html/template/
It doesn't have its own equivalent of RoR or Django yet because most of the batteries needed for web development are built-in.
My knowledge of this comes from the linked-to tutorial: "Web.go doesn't include a templating library. However, there are several good ones available, such as mustache.go. The template package in Go is not recommended for web.go because it doesn't allow templates to be embedded within each other, which causes a lot of duplicated text."
It seems that the web.go authors thinks that Go's template language batteries are of the wrong size.
It seems that the web.go authors thinks that Go's template language batteries are of the wrong size.
Web.go is sort of the Golang equivalent of Sinatra or Camping, not really of Ruby on Rails.
What you're looking for is Revel. http://robfig.github.com/revel/
What you're looking for is Revel. http://robfig.github.com/revel/
To be honest, I'm not looking. I'm only commenting that the original statement - that webgo is something like RoR - is incorrect. Thanks for the confirmation.
http://go-lang.cat-v.org/organizations-using-go
A very comprehensive list of the organizations using Go; I think it's kept reasonably up to date, but new ones are popping up on the mailing list from time to time.
For example, not to long ago we had the maintainer of pool.ntp.org asking some questions as he was rewriting some of the infrastructure for the pool from Perl to Go.
A very comprehensive list of the organizations using Go; I think it's kept reasonably up to date, but new ones are popping up on the mailing list from time to time.
For example, not to long ago we had the maintainer of pool.ntp.org asking some questions as he was rewriting some of the infrastructure for the pool from Perl to Go.
[deleted]
1) Python 3's backward incompatibility has made a mess of library support and has trapped us on Python 2.7.
2) memory usage is a problem on mobile for nontrivial Python programs; iOS isn't even a formally supported target.
3) Pythonic programs can't use multiple cores.
Now before you jump down my throat and tell me how bad a programmer I must be, etc, etc, let me provide some anticipatory clarifying comments:
1) Most libraries do now work in Python 3.3; we are waiting on gevent, pyasn1, and tlslite, and, of course, all our own stuff.
2) There's at least one fork of Python 3 on bitbucket with a bunch of promising memory-reducing changes (can't find it now).
3) Yes, I know about (multi)processing and that real threads are hard to work with.
Literally every few weeks we are confronted with a new problem caused by one of the above. The latest one: there is no WinRT port of Python yet, and the one Martin Loewis is working on is for Python 3.3. (Of course: Python 2.7 is barred from noncritical patches.) So we need to either make 2.7 work on WinRT or not ship a WinRT version. Windows 8 launches Oct 26; Python is frankly just not ready, and no one but Martin L and a few others seem to care (or even notice). (And yes, I know Win32 stuff still runs under Windows 8... but not on the ARM devices, and not in the UI-formerly-known-as-Metro.)
I wouldn't say I regret having chosen Python as the basis of a 250k-line system, because in retrospect it was still the best of the dynamic language choices. But I definitely feel like Python qua programming language has become a missed opportunity in many ways.
Nowadays if someone were to ask me what they should write a nontrivial new system in, I would probably recommend coding everything in JavaScript or C++11. This makes me sad, because Python's syntax and sensibility are unparalleled; I have never been as productive a coder as I have been coding in Python these last few years. And I've been coding in C dialects since, seriously, 1979 (on a Heathkit H89 with 64K of RAM!)