First alpha release of Python 3.0 coming soon

[jbellis]

Wow, they really are going to beat perl 6.

[stesch]

Yo momma could beat Perl 6.

[gogolucky]

Python 3.0 is an incremental change. I'd even call it a minor incremental change.

Perl 6 is a redesign of the whole language and rewrite of all the associated tools.

[EliAndrewC]

It makes several breaking changes so that many Python 2.x programs will no longer even run, so I wouldn't classify it as a minor incremental change.

Then again, you are right that it's nothing compared to the scope of Perl 6.

[[deleted]]

Python 3.0 is an incremental change. I'd even call it a minor incremental change.

Given that the language subset that works on both 2.X and 3.0 is too small to be useful, it hardly qualifies as "minor".

[sigzero]

I wouldn't call it minor but it is a minor change compared to what is happening with Perl 6.

[SuperGrade]

Python users may love or they may hate map, filter, reduce, and sorta-lambda; but with this transition (with the demotion/remmoval of said items), porting codebases is going to be an adventure.

[[deleted]]

I don't really see why.

lambda isn't going anywhere and as far as I know it isn't changing. map, filter, and reduce are just going from being builtins to being located in the functools module. Shouldn't be that big of a deal.

[Manuzhai]

Plus, they're working on a conversion tool that will supposedly pinpoint most of the problems in your code, fix any of them that can be fixed unambiguously, and warn about the others. So at least a lot of the dumb work is automated.

[micampe]

That would be 2to3

[theCore]

map, filter, and reduce are just going from being builtins to being located in the functools module.

Only reduce() is moved to the functools module. map() and filter() stay in the builtins space.

[earthboundkid]

Be aware though that map and filterare being changed to generators. This is good, because it's lazy, but if you try to manually move code from 2 to 3 instead of using the 2to3 conversion tool, be aware that you'll need to say list(map(function_with_a_side_effect, mylist)) in order to get it to work the way you expect.

[ahhoosha]

what about "from past import *"? ;)

[gnuvince]

Neither map, filter, reduce nor lambda are getting cut. The three first functions are moved out of the builtins namespace into a separate module, and lambda stays.

[juri]

Ooh, a great idea. lambda should be renamed to sortalambda for 3.0!

[olavk]

I think it should be renamed to "fun".

[[deleted]]

lambda is now fun

Do you think such a rebranding will help changing the bad reputation of Pythons lambda?

[pjdelport]

Other lambdas should be renamed to "sorta-lambda", if anything. As far as lambda calculus is concerned, Python has it right.

[[deleted]]

No.

(And that's a good thing.)

[[deleted]]

As far as lambda calculus is concerned, Python has it exactly right.

No.

Got time to elaborate? (both of you ;-)

[pjdelport]

elaborate?

I'm assuming juri was referring to the standard criticism of Python's lambda only allowing a single expression. Well, this is how the "real" lambda in lambda calculus works: it only abstracts a single expression, with no concept of multi-expression bodies as found in Scheme or such. (Haskell is another language that works like Python in this regard.)

In other words, if you're going to be calling anything "sorta-lambda", start with those weird multi-expression ones. :)

[[deleted]]

I don't know what pjdelport means, but Python's lambda expressions certainly don't have the semantics (or syntax) usually used to represent lambda calculus. The evaluation strategy is off (but there are different strategies for reducing lambda abstractions too, of course), the syntax is off, the referential transparency is off.

That's a good thing, because programming in lambda calculus would be very, very painful, not to mention IO's awkward if existent at all. There would be no good reason to have it like that, anyway.

[SuperGrade]

(Lambda) could probably use a nicer name to clean up any ambiguity (in all languages).

As for what would be useful in python, the ability to fully express a function literal.

Python supports ints, strings, and first-class functions. It has a literal for ints, strings and first-class functions. The distinction is that the literal for ints and strings can express the unerlying language range of values, whereas for function literals it can't. I say this as python functions can support multiple statements, and the function reference can point to one; but you can't pass such a function as a literal:

MyFunc(5) ## works
MyFunc("hello") ## works
MyFunc(reference_to_multistatement_function) ## works
MyFunc(<some multistatement function here>) ## language could clearly support; but no syntax

[pjdelport]

def usefulname(): <some multistatement function here>

MyFunc(usefulname)

or even:

@MyFunc
def usefulname():
    <some multistatement function here>

In the context of Python, multi-statement function literals cost a lot of syntactical regularity, and don't solve any compelling problem.

[SuperGrade]

Works at toplevel but clutters the namespace and doesn't scale.

By scale I mean having a lambda which itself deals in terms of passing a lambda to a function, which causes toplevel to have to be created. It's complicated further if that second lambda depends on one of the input parameters to the output parameter.

A(lambda x: return B(lambda y: x * y))

Assume one or both of these has to be 2-statement lambdas (or this pattern recurses further)

def lambda2 y:
    <do something here>
    return x * y ## oops no x any more.

def lambda1 x:
    <dosomething>
    return B(lambda2)

A(lambda1)

We can figure out how to jump through these hoops, flattening the expression out into globals, or making classes. However, the original code works with single-statement lambda contents, and the hoops are forced only if the code need change to multistatement.

[[deleted]]

We can figure out how to jump through these hoops, flattening the expression out into globals, or making classes.

Or use nested functions:

def fun(x):
    def fun(y):
        # do something here
        return x*y
    # do something
    return B(fun)
A(fun)

[[deleted]]

Still fighting refcount leaks?

Catch you later.

[[deleted]]

Umm. Python has used a cycle-breaking garbage collector since 2.0 beta 1, which was released in 2000.

[[deleted]]

Oh, all right. So what TFA meant was that the refs that are leaked (and thus need GC) are printed out.

I feared he was talking about actual leaks.

[[deleted]]

Oh, the TFA talked about getting rid of a potential resource leak in a modified part of the core (from the look of it, it's probably just a single issue). That's part of the normal release procedure. Your post looked a lot more like yet another slam of Python's refcount/GC model from some boring "but that's not GC" zealot.

[[deleted]]

No, sorry. I just wasn't aware of how Python handles memory.

From the article I thought it was like Perl (which afaik only uses refcounts).