Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bring back callable() #54727

Closed
pitrou opened this issue Nov 24, 2010 · 24 comments
Closed

Bring back callable() #54727

pitrou opened this issue Nov 24, 2010 · 24 comments
Assignees
Labels
interpreter-core Interpreter core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@pitrou
Copy link
Member

pitrou commented Nov 24, 2010

BPO 10518
Nosy @brettcannon, @birkenfeld, @pitrou, @benjaminp, @ezio-melotti, @merwok, @voidspace, @durban, @ambv
Files
  • callable.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/birkenfeld'
    closed_at = <Date 2010-11-27.22:00:39.566>
    created_at = <Date 2010-11-24.13:05:16.647>
    labels = ['interpreter-core', 'type-feature']
    title = 'Bring back callable()'
    updated_at = <Date 2010-11-27.23:00:39.816>
    user = 'https://github.com/pitrou'

    bugs.python.org fields:

    activity = <Date 2010-11-27.23:00:39.816>
    actor = 'pitrou'
    assignee = 'georg.brandl'
    closed = True
    closed_date = <Date 2010-11-27.22:00:39.566>
    closer = 'pitrou'
    components = ['Interpreter Core']
    creation = <Date 2010-11-24.13:05:16.647>
    creator = 'pitrou'
    dependencies = []
    files = ['19795']
    hgrepos = []
    issue_num = 10518
    keywords = ['patch']
    message_count = 24.0
    messages = ['122273', '122277', '122292', '122293', '122309', '122345', '122364', '122366', '122367', '122368', '122370', '122371', '122373', '122562', '122563', '122570', '122572', '122574', '122576', '122577', '122579', '122581', '122582', '122584']
    nosy_count = 10.0
    nosy_names = ['brett.cannon', 'georg.brandl', 'pitrou', 'benjamin.peterson', 'ezio.melotti', 'eric.araujo', 'michael.foord', 'SilentGhost', 'daniel.urban', 'lukasz.langa']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue10518'
    versions = ['Python 3.2']

    @pitrou
    Copy link
    Member Author

    pitrou commented Nov 24, 2010

    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.

    @pitrou pitrou added interpreter-core Interpreter core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels Nov 24, 2010
    @benjaminp
    Copy link
    Contributor

    benjaminp commented Nov 24, 2010

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

    @merwok
    Copy link
    Member

    merwok commented Nov 24, 2010

    Does the plan include deprecating collections.Callable?

    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Nov 24, 2010

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

    @ezio-melotti
    Copy link
    Member

    ezio-melotti commented Nov 24, 2010

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

    @ambv
    Copy link
    Contributor

    ambv commented Nov 25, 2010

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

    @pitrou
    Copy link
    Member Author

    pitrou commented Nov 25, 2010

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

    @voidspace
    Copy link
    Contributor

    voidspace commented Nov 25, 2010

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

    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Nov 25, 2010

    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.

    @voidspace
    Copy link
    Contributor

    voidspace commented Nov 25, 2010

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

    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Nov 25, 2010

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

    @voidspace
    Copy link
    Contributor

    voidspace commented Nov 25, 2010

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

    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Nov 25, 2010

    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.

    @pitrou
    Copy link
    Member Author

    pitrou commented Nov 27, 2010

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

    @pitrou
    Copy link
    Member Author

    pitrou commented Nov 27, 2010

    Committed in r86842.

    @pitrou pitrou closed this as completed Nov 27, 2010
    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Nov 27, 2010

    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.

    @pitrou
    Copy link
    Member Author

    pitrou commented Nov 27, 2010

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

    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Nov 27, 2010

    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?

    @benjaminp
    Copy link
    Contributor

    benjaminp commented Nov 27, 2010

    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.

    @pitrou
    Copy link
    Member Author

    pitrou commented Nov 27, 2010

    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?

    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Nov 27, 2010

    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.

    @pitrou
    Copy link
    Member Author

    pitrou commented Nov 27, 2010

    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.

    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Nov 27, 2010

    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.

    @pitrou
    Copy link
    Member Author

    pitrou commented Nov 27, 2010

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

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    interpreter-core Interpreter core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    7 participants