What’s New in Python 3.0

http://docs.python.org/dev/3.0/whatsnew/3.0.html

by alexk • 18 years ago

44 42 18 years ago

docs.python.org

ljlolel• 18 years ago

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!

mojuba8• 18 years ago

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.

j2d22• 18 years ago

print >>sys.stderr, "fatal error"

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

mojuba8• 18 years ago

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.

anewaccountname2• 18 years ago

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

alexk2• 18 years ago

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'

mojuba8• 18 years ago

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.

eru5• 18 years ago

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

mojuba8• 18 years ago

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

KirinDave2• 18 years ago

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.

globalrev• 18 years ago

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.

bkovitz3• 18 years ago

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

eru5• 18 years ago

You should be yearning for proper tail recursion instead.

KirinDave2• 18 years ago

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.

pavelludiq• 18 years ago

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

eru5• 18 years ago

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

lolb• 18 years ago

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

eru5• 18 years ago

Haskell 2000!

signa11• 18 years ago

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

anewaccountname2• 18 years ago

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

bkovitz3• 18 years ago

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.

BrandonM2• 18 years ago

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.

bkovitz3• 18 years ago

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?

andy• 18 years ago

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

nostrademons• 18 years ago

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

danohuiginn• 18 years ago

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?

What’s New in Python 3.0

Related Stories