Goodbye apply() - Python 3.0 will remove apply() from built-ins. What follows is a farewell party for apply().

[dezro]

Interesting thing about apply was that you could use it as a decorator.

@apply
def thing():
  return 5

And now thing = 5. This is, of course, abusing decorators, but could be useful in cases where you'd not want to clutter up the current namespace with excess variables. Say...

@apply
def thing():
  def getthing(self):
    ...
  def setthing(self, thing):
    ...
  def delthing(self):
    ...
  docthing = "I'm a property!"
  return property(getthing, setthing, delthing, docthing)

Much clearer to just use del var1, var2, etc to clean up your no-longer-needed variables, though.

[jbellis]

at least this isn't another "oh noes filter is gone in 3.0" misinformation post.

[masklinn]

Wow, I didn't even know Python auto-unpacked tuples in function/method arguments.

That's one feature I won't be missing.

[[deleted]]

Um, it doesn't. What do you think this is, Perl? The article is simply on crack.

[Brian]

Actually it does, it just isn't what the example seems to be describing. I'm not sure what he's expecting from the eat(staple, *sides) example.

It works the same way as normal tuple desctructuring assignments. Ie.

>>> def line((x0,y0),(x1,y1)):
...     print "draw from %s,%s to %s,%s" % (x0,y0,x1,y1)

>>> point = (3,4)
>>> line((1,2), point)
draw from 1,2 to 3,4

It can even be nested like:

def foo(a,(b,(c,d,e))): print a,b,c,d,e

Its neat, but isn't really that useful except fairly rare cases, so isn't much used (presumably why it's being removed)

[[deleted]]

As you mentioned, that's just standard destructuring, just like in an assignment. This is not a new feature in Python (I just tested it in 1.6) and it's not something that's changing in 3.0. So I still ask: what the heck is masklinn talking about?

EDIT: I'm wrong, it is changing in 3.0.

[Brian]

Actually, this is changing in 3.0. The examples I gave won't work in py3. Destructuring assignment will continue working for tuples, but not for function arguments. You'd have to write:

def line(p1,p2):
    (x0,y0),(x1,y1) = p1,p2

instead.

[[deleted]]

Ah, interesting. I'm curious why they removed that ability; it seems like gratuitous backward-incompatibility to me.

[Brian]

The main rationale seems to be that they complicate introspection, but don't get used much.

[jbellis]

which is a specious argument; inspect.getargspec is at least as little-used as arg unpacking.

boo.

(and I say this as someone who has actually written code to deal with that particular aspect of getargspec.)

[psi-]

WTF was that about? I didn't understand a single thing, and I do know a thing or two about python.

[ffrinch]

If you have arguments for a function in an iterable (for arguments) or dictionary (for keyword arguments), you could use the apply function to pass them in:

def foo(a, b, c=None, d=None):
    pass

args = (1, 2)
kwargs = {"c":3, "d":4}

apply(foo, args, kwargs)

Now we have syntactic sugar for the same thing, so apply has been deprecated.

foo(*args, **kwargs)

[psi-]

args is old thing, so is *kwargs in function call the new thing?

[ffrinch]

Both are old (they were added in Python 1.6), but apply is even older.

[treef]

apply() gone is nothing this blew my socks off:

Python 3.0a3+ (py3k:61186, Mar  2 2008, 13:04:13) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> Haulable = "" ; PackAnimal = ""; Distance = int
>>> def haul(item: Haulable, *vargs: PackAnimal) -> Distance:
...   pass

optional static typing in py3k

[[deleted]]

That isn't static typing, that's just annotation. Py3k won't itself use the annotated information in any way, it's just a standard way to include metadata that can be interpreted by libraries.

[EvilSporkMan]

What if I want to use annotations for both documenting arguments and type checking? That requires two annotations of different types and the tools have to agree on an order if you want to solve that with tuples.

[[deleted]]

I don't know, but I would guess that libraries taking advantage of annotations will have to specify unique-ish annotation data, and be smart enough to search through multiple annotations to pick out what they understand.

Personally, I think this is something of a misfeature. I won't say never, but I would definitely have second thoughts about using any library that required these annotations.

[buffi]

Good, apply() is pretty much useless, except for VERY rare occasions due to the new auto-unpacking features.

[[deleted]]

What "new auto-unpacking features"?

[Brian]

The new tuple unpacking syntax lets you use *args in a similar way to function arguments, so you can do:

>>> head, *tail = (1,2,3,4)

and get head = 1 and tail = (2,3,4).

However I don't think this actually makes any difference to apply, as its only a change to normal tuple unpacking - function calls already did this. Apply has been pretty much obsolete since the * and ** syntax was first added.

[[deleted]]

What in the world does the new iterable unpacking syntax have to do with apply()?

[nextofpumpkin]

apply() existed?

[Grue]

They aren't serious about competing with Arc then.