What’s New in Python 3.0 | Hacker News Reader

What’s New in Python 3.0

docs.python.org

44 pointsalexk42 comments

I love the changes to the language to remove the warts and to improve consistency across the language. Python thrives on consistency and always having exactly one obvious, readable way to do something. I welcome the simplified integer math, print function, unicode string unification, and other changes.

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!

I really wish they had added real lambdas.

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.

what does a real one consitute of?

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.

Sometimes, I just want to pass a function to a function. And sometimes, I want to just say, very concisely, "do this", without giving a name to "this".

But you can do that in both python 3 and 2.5...

Maybe he's talking about

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

Were you expecting 3? Lambdas (besides having such an awfully long and difficult to type name :P) capture only the "name" of x, so when the for loop changes x later, the lambda sees the new value--so the sum is (2 + 2 + 2) instead of (1 + 2 + 3).

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

By using x as a default argument, you force the x inside the lambda to be the value it was when the lambda was created. It kinda sucks, and always felt to me like a deficiency of the implementation leaking up into the language :[

I think you mean "2 + 2 + 2 instead of 0 + 1 + 2"

You should be yearning for proper tail recursion instead.

I can live without this. I cannot live without real lambdas. My heart actually will stop, and I will die. It's a dangerous world I live in.

WTF? Why doesn't the new repr(1L) return "1L"? I thought the whole point of the repr custom was to output something that would regenerate the same object.

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.

WTF? Why doesn't the new repr(1L) return "1L"? I thought the whole point of the repr custom was to output something that would regenerate the same object.

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];

My module uses string interpolation on this file, but it defines a special class with a __getitem__ method that instead of simply returning the associated string (as a dict would), it evaluates an arbitrary Python expression. And it works! It's pretty cool to be able to mix C and Python in this way to more easily write C code.

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

Assuming that pyvar_months is

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

(in Python), the automatically-generated C result will be:

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


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

Okay, sorry to go so off topic, but I really wanted to show that it's possible to use the current string interpolation functionality to do really cool stuff, and it would be a shame to see that change.

Muchas gracias for the explanation of repr. I knew I shouldn't have lost faith in Guido.

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?

No, although it could potentially be modified to fulfill that purpose. Its purpose is best described as providing a macro system that allows some C code to be generated by more-succinct Python code.

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.

Python 3.0 is going to be better, but not much better. I really like python because its very clean. Python 3.0 shouldn't become python++.

I hate the new print(x) changes in Python. Dammit! I loved typing print x.

IPython. You can leave off the parentheses on all function calls where ambiguity does not result.

I'm worried about the hassle as every 'hello world' tutorial stops working. The change has been on the cards for yonks, and the print('foo') version has always been valid - why hasn't there been a push to get the documentation changed before introducing the change?

print("fatal error", file=sys.stderr)

So, Python has become even less succinct for the sake of "consistency".

I think there is only one flawless, absolutely consistent machine, and that's Turing machine. The urge for consistency and simplification (I mean, if you are consistent in your aspiration for consistency) inevitably leads to reinventing the Turing machine in its purity. It's OK, except for some reason nobody wants to program for it.

print >>sys.stderr, "fatal error"

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

I never liked that either, but the new version is physically longer and requires more typing. Moreover, I couldn't find any change in 3.0 that results in less typing. I might have missed something of course, but this announcement doesn't seem to be something to be excited about.

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.

from pep 3099:

    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.

Thread: "genexp syntax / lambda", http://mail.python.org/pipermail/python-3000/2006-April/0010...

I understand there are syntactic obstacles, in fact I've been following these discussions, but... I'm very sorry, who cares?

> you are not supposed to do this, says Python to you, because it's a bad practice and can lead to errors.

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.

Curiously, this approach is usually welcomed in corporate environments. Java and C# are on the same shelf in this regard. It limits creativity by leaving no doors for new ways of doing things. Certain class of programmers just can't bear when they are told what's right and what's wrong in programming.

Java, especially if you get into the OOP patterns fun, can present a million ways of doing things. Java is terrible about this.

sys.stderr.write("fatal error\n")

You'll still be able to do that.

You can always consider print as low-level feature and wrap the whole thing in a fancy stream.

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

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

Of course I can do it, then why isn't it done already in the language?

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.

That's because really cool languages provide you with the power to build what you want, not the ton's of built-in fancy features.

There is one advantage in having necessary stuff built into the language: others can understand your code quickly.

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

Turing's machines are clunky. Do lambda calculus or grammars instead.

Lambda calculus is beautiful, but modern computers are not lambda machines.

Is there a problem which can be solved in Lambda Calculus that cannot be solved in a Turing Machine?

A Lambda machine can be implemented using a Turing machine, but not the other way around, which means, Lambda calculus is a subset. Correct me if I'm wrong.

nope, they're turing equivalent. read up on the church-turing thesis.

They are lambda isomorph.

is hex(-1) still '-0x1' ?

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

Instead of

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.)

Instead of writing Python 3000, they shoulda written another Haskell!!

Haskell 2000!

Reply on news.ycombinator.com