It was just resting. Here is a patch to wake it up for 3.2 (or 3.3 pending moratorium interpretation).

As for the py3k warning in 2.x (and the 2to3 fixer), it's not obvious what we should do: callable() clearly doesn't exist in 3.0 and 3.1.

I think we should lift the py3k warning after 3.2 is released, but leave the 2to3 fixer in for the time being.

Does the plan include deprecating collections.Callable?

What is the reason for this? Why do we need it?

I'm not sure it's worth bringing callable() back at this point.
It would have made more sense for 3.1, but now we already have 2 callable()-less versions of Python if we do it for 3.2 (what about the moratorium though?) or 3 if we do it for 3.3. Also if isinstance(obj, collections.Callable) is correct in what it does, it's trivial to do something like:

def callable(obj):
  return isinstance(obj, collections.Callable)

If it goes in the iscallable name suggested on python-dev might be better (IMHO). At least people will realize that it's something "new" and don't assume that the old callable() has been there all the time (it also clear that it returns a boolean and reads better in e.g. if iscallable(obj): ...).
(The patch should also include an entry in the table at the top of functions.rst now that I committed bpo-10299 in r86732.)

I was originally surprised to find that callable() was gone. I pointed it out at Europython and got a very informative explanation from Brett. The isinstance(obj, collections.Callable) was introduced and it works well.

I'm with Ezio here. I'm -1 for callable(), +0 for iscallable() (there should be preferably one obvious way to do it and using isinstance() seems to be that way at this point).

I'm with Ezio here. I'm -1 for callable(), +0 for iscallable() (there
should be preferably one obvious way to do it and using isinstance()
seems to be that way at this point).

The thing is, "isisinstance(x, collections.Callable)" is hardly obvious
to anybody, while callable() is.
As for the naming, it's the same as in 2.x, which is a good enough
reason for me. Nobody stops you from calling your callables "callable"
anyway, or your maxima "max" and your sums "sum".

Bringing back callable but with a different name is horrible. Just bring it back for goodness sake.

Just for the reference: "What's new in Python 3.0" page says:

Removed callable(). Instead of callable(f) you can use isinstance(f, collections.Callable). The operator.isCallable() function is also gone.

There doesn't seem to be any indication than in two-versions time anyone would feel a need to resurrect it.

It might be not "obvious", but it's consistent with the check for other attributes. And I doubt that it's any more non-obvious than the need to use it in a first place.

Well, Guido has already approved its return - so further debate is relatively pointless. (Not that that usually stops us...)

surely, such a relevant bit of information is worth linking to!

It was on python-ideas in the recent thread about bringing back callable. Feel free to post a link here for the record.

I wouldn't consider it "approving", what Guido says is:

I admit defeat on this one

<http://mail.python.org/pipermail/python-ideas/2010-November/008747.html\>

Which incidentally is in response to your e-mails with the actual discussion following it.

It might be not "obvious", but it's consistent with the check for other
attributes.

I don't know what attributes you're talking about, and there doesn't seem to be a lot of consistency there.
Besides, being consistently obscure and hard to find is not the good type of consistency :)

Committed in r86842.

I thought PEP-3003 was quite unambiguous:

This PEP proposes a temporary moratorium (suspension) of **all changes** to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1. In particular, the moratorium would include Python 3.2 (to be released 18-24 months after 3.1) but allow Python 3.3 (assuming it is not released prematurely) to once again include language changes.

Le samedi 27 novembre 2010 à 22:23 +0000, SilentGhost a écrit :

SilentGhost <michael.mischurow+bpo@gmail.com> added the comment:

I thought PEP-3003 was quite unambiguous:

The stated goal of the moratorium is to make it easier for alternate
implementations to catch up with the current language specification.
Bringing back callable() doesn't go against this goal since they already
have implemented it for 2.x.
(not to mention that the implementation should be very simple)

I wouldn't claim this is a authoritative interpretation but, if Guido
doesn't oppose, I would take it for valid :)

I thought that moratorium meant Guido dis/approval is not applicable to the 3.2

Another listed change was help ease adoption of py3k. How's that helping?

2010/11/27 SilentGhost <report@bugs.python.org>:

SilentGhost <michael.mischurow+bpo@gmail.com> added the comment:

I thought that moratorium meant Guido dis/approval is not applicable to the 3.2

Another listed change was help ease adoption of py3k. How's that helping?

By causing one less discontinuity.

I thought that moratorium meant Guido dis/approval is not applicable to the 3.2

Guido can decide of everything: PEPs, etc. That's what "BDFL" means.
So he can also decide of exceptions to the rules he decided on.
(rules can have exception in any reasonable human society)

Another listed change was help ease adoption of py3k. How's that helping?

How's it not helping?

I'm not sure what your general point or concern is. Do you have a real
problem with callable() coming back or is it just a formal argument?

yes, my problem is that callable was removed and a way was shown how to do this check. The way which is consistent with the check for any other type (ABC). Now out of the blue, w/o any justification this way is going to be ignored, because "ah, sure. I can't be bothered typing extra three characters" and the old function is reintroduced.

I don't like that we're heading into Perl's direction. that's all.

yes, my problem is that callable was removed and a way was shown how
to do this check. The way which is consistent with the check for any
other type (ABC).

ABCs are still the exception in Python, and duck typing is still the
rule.

I don't like that we're heading into Perl's direction. that's all.

Well, please deal with it.

ABCs are still the exception in Python, and duck typing is still the
rule.

Then why do we callable again?

Don't worry, I'll deal with it. It's not like this whole discussion mattered.

> ABCs are still the exception in Python, and duck typing is still the
rule.

Then why do we callable again?

Because the way __call__ is looked up means hasattr(x, "__call__") is
not the right answer. Otherwise there would be no point in bringing it
back at all.