However, the biggest change, potentially, is function annotation. Function annotation brings the possibility of an extra level of documentation in code, of static-style type-checking which can easily be turned off in production, and of a standardized design by contract programming style.

Hopefully, we will have even bigger, easier to understand Python programs!

Don't get me wrong, these changes seem good. But every time I hear about a new Python release I keep hoping that I'll see they've finally reversed their policy about lambdas and made a real one instead of the compromise they have right now.

and why do you want that? i use pyhton as a superb general-purpose language and for gluing together a lot of different parts of software/programs.

for that purpose, simplicity and readability is essential.

    >>> funcs = []
    >>> for x in xrange(3):
    >>>   funcs.append(lambda: x)
    >>> sum(f() for f in funcs)
    6

What you can do, instead (and I do it often enough that I wish lambdas created their own lexical closure....)

    >>> funcs = []
    >>> for x in xrange(3):
    >>>   funcs.append(lambda x=x: x)
    >>> sum(f() for f in funcs)
    3

Are they going to abandon the 'Format %d:%s" % (n, s)' or just add PEP 3101? The % syntax is down-and-dirty practical good. PEP 3101 is neat, but printf() syntax is tough to beat.

OK, the first screenful or so scared me. The rest looks like clear-cut improvements.

So far, I've loved Python's balance between simple purity and down-and-dirty pragmatism. I sure hope they don't shift too far toward purity.

Because there's no such thing as 1L anymore. There is one unified (unbounded) integer, and I believe the C implementation will use int to represent small values and long when necessary (and list of long beyond that?).

Are they going to abandon the 'Format %d:%s" % (n, s)' or just add PEP 3101? The % syntax is down-and-dirty practical good. PEP 3101 is neat, but printf() syntax is tough to beat.

I'm a little worried about this as well. I just wrote a ctemplate module that leverages % syntax a lot, so it would be quite unfortunate to see it disappear.

In other words, you could write code like:

  char * months[%(len(pyvar_months))d];

That may seem minor, but I've used the same framework to be able to say:

  %(array; char *; months; ['"%s"' % (mo,) for mo in pyvar_months])s

  ["January", "February", "March", ..., "December"]

  /* header file */
  extern char * months[12];


  /* C file */
  char * months[12] = {
      "January",
      "February",
      "March",
      ...,
      "December"
  };

The ctemplate sounds really frickin' interesting. Is this an easy way to get a major performance boost on CPU-intensive bits of Python? Actually, this is probably getting off-topic, but will you email me when ctemplate is ready for prime-time?

By the way, you e-mail is not in your profile. You can send me an e-mail (in my profile), and I'd be happy to keep you posted.

Considering this is this old version of what you copied, I don't think anything has been lost...

I was waiting, for example, lambdas to be allowed to have compound statements. Python, a nice language otherwise, could have been improved in many ways, none of which is found in 3.0.

Instead, the spirit of Python is coming closer and closer to Java: you are not supposed to do this, says Python to you, because it's a bad practice and can lead to errors.

I'm disappointed and I think I'd rather wait for another, more concise nobraces programming language.

    At one point lambda was slated for removal in Python 
    3000. Unfortunately no one was able to come up with a 
    better way of providing anonymous functions. And so 
    lambda is here to stay.

    But it is here to stay as-is. Adding support for 
    statements is a non-starter. It would require allowing 
    multi-line lambda expressions which would mean a  
    multi-line expression could suddenly exist. That would  
    allow for multi-line arguments to function calls, for  
    instance. That is just plain ugly.

Isn't that one of the main themes of Python? That you can expect another programmer to have solved the same problem almost the same way..? I figure this is how that happens.

    class err_class:
        def __lshift__(self,other):
            print(other)
            return self

    err = err_class()
    err<<'fatal error:'<<'thats what happened'

Printing is something we do all the time in server applications, and that means, the printing facility in the language should be polished to death.

As for printing, it is so basic and simple, if implemented right of course, that I wouldn't call it "tons of fancy features".

    In [1]: hex(-True)
    Out[1]: '-0x1'

print("string")

I would have liked to see

fn op1 op2

to be the standard function invocation - like in Haskell. (I know that would have wreaked havoc with the rest of Python's syntax.)