Looking back Python 3 came too late, didn't offer much in terms of an incentive to justify switching to it, divided the community and in the process also left other things people worry about by the wayside -- performance, packaging, better concurrency handling (no not via Tulip or Twisted).

I think, like you point out, many before they decided to sink the time into upgrading to Python 3 to get better unicode support for example, would also take the time to evaluate and go with something else altogether -- Go for example.

Then well ok, the answer to "What did Python 3 bring to the Python community?" becomes "Yeah it ended up driving a lot of people away", which I am sure wasn't the intended purpose of Python 3.0

benefit(2->3 + performance benefit + maintainability) <

benefit(2->Go + performance benefit + maintainability)

The time cost of 2->3 will be less but if I know I will get better memory footprint, and faster response times I might be willing to invest some more time into it.

Or another way to look at it, once one sits down and rolls their sleeves looking to re-factor/renew/refresh the code base there is a good chance they will look around them and see what else is out there.

It's also quite an issue for COTS software - sometimes to jump forwards and clean up APIs they have to do a huge refactor, sometime even a re-write of the API. If this is troublesome enough, it's worth taking the time to look into the competition.

GIL only exists on CPython, there are other implementations.

PyPy is not really a good example here. It is still highly experimental, takes long time to compile, it's not compatible with quite a few libraries in normal Python, and still has all relative downsides of dynamic typing. To be frank, I don't get the point of using PyPy instead of Go.

Previously most Python libraries already use C to optimize critical components. If you can use just one language to get similar performance, why do you bother using two then?

Or do you mean some other style of concurrency primitives?

Sounds like a good topic for a post (or at least a link - hint, hint).

https://code.google.com/p/pycsp/

https://code.google.com/p/go/issues/detail?id=6853

HHVM and now PHP 5.7-dev, both with JIT - the future of PHP looks bright.

Starting a new project, we would choose PHP, Node.js or Go according to the requirements.

But you might actually not like to hear Node's V8 engine is between 50 and 150 times faster than PHP in synthetic benchmarks, and about 20 times faster in more diversified applications (as long as they don't sit an eternity blocking waiting on a DB call which is the way people did web apps 10 years ago). That's 2000% faster than PHP, just so we use the same units here.

I'm very happy PHP is getting faster and all, but just don't juxtapose it next to JS engines (which the article talks about), let alone something more serious like the JVM, because the "bright future" of PHP starts looking quite dim in comparison.

Check out an independent benchmark for comparision: http://www.techempower.com/benchmarks/#section=data-r9&hw=i7...

PyPy is good. I wish there was more moment and more _pull_ for it from the main Python team. I feel the big push for the last 3-4 years should have been for PyPy (or performance and tooling in general).

EDIT:

To expand, I remember feeling so excited during the PyCon-s in Chicago and then Atlanta. Unladen Swallow was making some progress but PyPy was fantastic, great speed improvements. Everyone looked in awe at you guys, and your presentations. We talked about STM and all the great things.

And then...Guido announced in a rather annoyed tone how PyPy will never be a part of main Python distro and that's that. "Stop dreaming folks". And that made me pretty disappointed.

Then the drumbeat for Python 3.0 started. Unicode, unicode, unicode... it got louder and louder.

The wall of shame for "incompatible" libraries that were not being ported to Python 3.0. Lots of how to migrate and to Python 3 talks. Lots of oh look at the great view iterators.

Things that would make me get off my seat and start porting to Python 3 would be: greenlet integration for low memory, concurrency green threads (gevent and eventlet). Great CPU speed improvement with included PyPy. Notice what is not on the list -- unicode, view iterators and renaming Queue module to queue. Sorry if I am being too sarcastic here, it is because I am bitter about it.

It is also important to realize that Python 2.0 is just very good that it becomes hard for Python 3.0 to beat it. There were not big hairy warts that just bothered me about it. So it isn't that Python 3.0 is bad, it is not, it is just not better enough Python 2.0.

Now I agree with you having PyPy's performance improvements in the main implementation would be awesome, and PyPy itself is quite impressive. If they could get both NumPy running on PyPy and support Python 3's changes, it would keep Python a strong competitor for the foreseeable future.

And to your last point, I entirely agree Python 2.0 had so many strengths that it's really hard to improve upon it. Though I think that it's unicode support was the big hairy wart.

Perhaps you are right. My bitterness was coming through. It no t just that he said but how he said it.

In a way Python 3.0 also broke compatibility, for what I think, are not very good reasons. Some of that code was from people/companies who have adopted and used Python and made it popular. They are now living on a dead-end maintenance only branch.

None of those things make me want to get up roll up my sleeves and say "I can't wait to dig in and make my code compatible with 3.4". If I woke up tomorrow and someone would have magically done that for me and tested it, yeah great. I would buy them a beer. But that is about it. I have 0 incentive today to upgrade.

Code works very well now just using unicode support from Python 2 and print as a statement + other warts.

As the article says, Chrome's performance shows wide variation, even after JIT warmup. It's ranging from 50K/sec to 320K/sec. Bizarre.

The interpreters (esp CPython) need some hardcore engineering (like how javascript got V8). Languages that have the same theoretical performance limits of Python are now blowing it out of the water.

The stories about teams that were able to go down from N servers to 1 server by switching from Python to Go/Scala/node.js will hurt it in the long run.

Which python community are you talking about? Cython, numba, numpy, pypy?

> The stories about teams that were able to go down from N servers to 1 server by switching from Python to Go/Scala/node.js will hurt it in the long run.

Have you followed anything that is going on or just link-bait articles? Nearly everyone that re-implements something in another language uses different paradigms during the re-implementation, because they've learned something from the original implementation. Besides, those articles normally don't discuss any of the opportunity cost of re-invention or the long-term maintenance costs. I'm not saying they can't improve those things, but until you have the TCO over a few years, it's not an accurate portrayal.

concurrency designs and architecture play a greater role than the language , most of the times.

Bottle-necks are often in bad-sync patterns , data-structures or overall designs.

Language plays the role for semantic verification,formal models (for model-comparison...) ,type-system designs , proof systems etc .GIL is just one!

Can't compare language vs another.

After which the buck passes on to underlying implementation but cpython in our discussion is only thrown as a reference implementation and for production grade interpreters we might have to look outside like one by enthought.

However language's built-in patterns to help advertise concurrency is another question altogether.

Python, on the other hand, is definitely one of the worst at this. You can only create one-line, single-expression anonymous function with its lambda keyword. Of all the languages you want to convert to JS so that it runs on the browser, Python is probably the last.

I've had great usage from Javascript where I have separate functions with proper names and formatting, and then pass a reference to them into the code that asks for them.

Can someone please enlighten me about this whole anonymous functions thing that Javascript seems to have popularized? What are some of the pro's of using it over regular named/defined functions that sit by themselves and are reusable.

The OP is complaining about lambda functions in Python.

As to any complaint, lambdas exist in python (that is, are made accessible to the programmer) for the exact reason python also has a for loop in addition to a while loop -- because they make things easier and more maintainable.

  def myApplyAdd(func, x):
    return lambda y: func(x+y)

  applyAddInst = myApplyAdd(lambda z: z*2, 20)
  applyAddInst(3) #output 26

  def myApplyAdd(func, x):
    def innerAdd (y):
      return func(x + y)
    return innerAdd

  def mulByTwo(x):
    return x*2

  applyAddInstance = myApplyAdd(mulByTwo, 20)
  applyAddInst(3) #output 26

  lambda i: i**2

  result = [ i**2 for i in range(3, 30) ]

If a function is "assigned to a variable" then it's no longer a lambda, because it's bound to an identifier. But I suppose the lines are a tad blurred.

  x = lambda x: x+x #a lambda, but has a named pointer
  x = 5

  def x(y):
    return y+y
  
  x = 5 #the "named" function above is now without a pointer

  //lambda expression
  var x = function (){};

  //named function
  function x() {}

  //named lambda expression
  var x = function x() {};

  //self-executing lambda (returns 5)
  (function (x) {return x;}(5));

  (lambda x: x)(5)

  my_module = (function (self) {
    "use strict"
    self = self || {};

    //private
    //pretty much inaccessible to the outside scope
    var privateVar = 5;
    //lambda expression again
    var privateFunc = function () {};

    //public
    self.publicVar = 5;
    self.publicFunc = function () {};
    self.getPrivateVar = function () {
      return privateVar;
    };

    return self;
  }(my_module));

  my_module.publicVar = 8;
  my_module.publicFunc();
  my_module.getPrivateVar();

  func1(function () {
    func2(function () {
      func3(function () {
        func4(function () {
      })
    })
  })

Faced with squeezing an explanation into a limited post or recommending one of the best books on computer science (written by teachers with many years experience in teaching these self-same principles), should I not recommend the book that will allow the poster to expand his/her horizons?

The poster was sufficiently motivated to ask the question. I was willing to post what I believed at the time to be the best answer to the question. If the poster's desire to know is sufficient, then he/she will take the time to explore the suggestion. If not, then things will stay as they are. In either case, my only interaction is my choice to share a suggestion or remain silent.

However, I'm about halfway through the chapter on "Higher order procedures" in the book you linked to, and have skimmed the rest of that chapter. And I've yet to find a valid pro for anonymous methods. Nothing I've found so far as to the benefit of using anonymous functions.

It does however, continuously reiterate the benefit of being able to pass "procedures as arguments" and to be able to return them from normal functions. So far, that's been the only "pro" and it's one that's solved by function pointers or having functions as objects, and not by anonymous methods. I'm still open for convincing, genuinely.

Here's another jewel from that chapter: "The resulting procedure is just as much a procedure as one that is created using define. The only difference is that it has not been associated with any name in the environment."

On a side note, your initial post was a tad condescending. The other post at least gave me the relevant chapter, instead of saying "here, read this for yourself". The least you could have done was give me a few short points why you think anonymous methods are superior in some way. Perhaps pointing me to a large blob of text was your way of deferring your own justifications for their use by not having to explain it to me (and as a consequence, yourself)?

SICP's point with higher-order functions is that code is data and that functions are no different than numbers or lists or whatever. In the function below, I've named everything.

  def add4Mul2(x):
    z = 4
    y = 2
    return (x + y) * z

  lst = [1,2,3,4]
  x = map(add4Mul2, lst)

  x = map(lambda x: (x+2)*4, [1,2,3,4])

What a petty, it seems Google's forking of Webkit (named Blink) has hurt Webkit. Google's behavior of removing "CSS regions" was an unacceptable move.

    test.pystone.main()

Chrome on desktop -- 200K/s

pypy on desktop -- 2000K/s

http://arewefastyet.com/#machine=12&view=breakdown&suite=asm...

That's not in release versions of Safari yet, it was just enabled on trunk. But it will make Safari very competitive once more.

In the meantime, browsers would still be free to compete based on their JIT implementations.

With rust and by proxy, Mozilla/Samsung's experimental Servo layout engine targeting the LLVM, I can also see potential synergy in this situation.

    CPython 2.7.5:  27032
    PyPy.js:        20103
    PyPy 2.0.2:    444011

    OK OK, I couldn't resist that title but it probably goes a bit far. Let me try for
    a little more nuance:
        PyPy.js: Now faster than CPython, on a single carefully-tuned benchmark,
        after JIT warmup.

"pypy.js is really fast, why not use it instead of CPython?".

It's saying:

"Consider using pypy.js on the client, it's comparable in performance to native CPython; you consider that fast enough."