Mailman 3 September 2009 - Python-checkins

r75099 - peps/trunk/pep-0389.txt
by steven.bethard 27 Sep '09

27 Sep '09

Author: steven.bethard Date: Sun Sep 27 23:03:21 2009 New Revision: 75099 Log: Update PEP 389 (argparse) Post-History. Modified: peps/trunk/pep-0389.txt Modified: peps/trunk/pep-0389.txt ============================================================================== --- peps/trunk/pep-0389.txt (original) +++ peps/trunk/pep-0389.txt Sun Sep 27 23:03:21 2009 @@ -8,7 +8,7 @@ Content-Type: text/x-rst Created: 25-Sep-2009 Python-Version: 2.7 and 3.2 -Post-History: +Post-History: 27-Sep-2009 Abstract

1 0

r75098 - python/trunk/Doc/library/unittest.rst
by michael.foord 27 Sep '09

27 Sep '09

Author: michael.foord Date: Sun Sep 27 22:08:23 2009 New Revision: 75098 Log: Documentation improvement for load_tests protocol in unittest. Issue 6515. Modified: python/trunk/Doc/library/unittest.rst Modified: python/trunk/Doc/library/unittest.rst ============================================================================== --- python/trunk/Doc/library/unittest.rst (original) +++ python/trunk/Doc/library/unittest.rst Sun Sep 27 22:08:23 2009 @@ -1281,6 +1281,7 @@ ``load_tests`` does not need to pass this argument in to ``loader.discover()``. + .. versionadded:: 2.7 The following attributes of a :class:`TestLoader` can be configured either by subclassing or assignment on an instance: @@ -1545,6 +1546,10 @@ load_tests Protocol ################### + +.. versionadded:: 2.7 + + Modules or packages can customize how tests are loaded from them during normal test runs or test discovery by implementing a function called ``load_tests``.

1 0

r75097 - peps/trunk/pep-0389.txt
by brett.cannon 27 Sep '09

27 Sep '09

Author: brett.cannon Date: Sun Sep 27 21:42:40 2009 New Revision: 75097 Log: Add PEP 389: argparse - new command line parsing module. Added: peps/trunk/pep-0389.txt (contents, props changed) Added: peps/trunk/pep-0389.txt ============================================================================== --- (empty file) +++ peps/trunk/pep-0389.txt Sun Sep 27 21:42:40 2009 @@ -0,0 +1,224 @@ +PEP: 389 +Title: argparse - new command line parsing module +Version: $Revision$ +Last-Modified: $Date$ +Author: Steven Bethard <steven.bethard(a)gmail.com> +Status: Draft +Type: Standards Track +Content-Type: text/x-rst +Created: 25-Sep-2009 +Python-Version: 2.7 and 3.2 +Post-History: + + +Abstract +======== +This PEP proposes inclusion of the argparse [1]_ module in the Python +standard library in Python 2.7 and 3.2. + + +Motivation +========== +The argparse module is a command line parsing library which provides +more functionality than the existing command line parsing modules in +the standard library, getopt [2]_ and optparse [3]_. It includes +support for positional arguments (not just options), subcommands, +required options, options syntaxes like "/f" and "+rgb", zero-or-more +and one-or-more style arguments, and many other features the other +two lack. + +The argparse module is also already a popular third-party replacement +for these modules. It is used in projects like IPython (the Scipy +Python shell) [4]_, is included in Debian testing and unstable [5]_, +and since 2007 has had various requests for its inclusion in the +standard library [6]_ [7]_ [8]_. This popularity suggests it may be +a valuable addition to the Python libraries. + + +Why aren't getopt and optparse enough? +====================================== +One argument against adding argparse is that thare are "already two +different option parsing modules in the standard library" [9]_. The +following is a list of features provided by argparse but not present +in getopt or optparse: + +* While it is true there are two *option* parsing libraries, there + are no full command line parsing libraries -- both getopt and + optparse support only options and have no support for positional + arguments. The argparse module handles both, and as a result, is + able to generate better help messages, avoiding redundancies like + the ``usage=`` string usually required by optparse. + +* The argparse module values practicality over purity. Thus, argparse + allows required options and customization of which characters are + used to identify options, while optparse explicitly states "the + phrase 'required option' is self-contradictory" and that the option + syntaxes ``-pf``, ``-file``, ``+f``, ``+rgb``, ``/f`` and ``/file`` + "are not supported by optparse, and they never will be". + +* The argparse module allows options to accept a variable number of + arguments using ``nargs='?'``, ``nargs='*'`` or ``nargs='+'``. The + optparse module provides an untested recipe for some part of this + functionality [10]_ but admits that "things get hairy when you want + an option to take a variable number of arguments." + +* The argparse module supports subcommands, where a main command + line parser dispatches to other command line parsers depending on + the command line arguments. This is a common pattern in command + line interfaces, e.g. ``svn co`` and ``svn up``. + + +Why isn't the functionality just being added to optparse? +========================================================= +Clearly all the above features offer improvements over what is +available through optparse. A reasonable question then is why these +features are not simply provided as patches to optparse, instead of +introducing an entirely new module. In fact, the original development +of argparse intended to do just that, but because of various fairly +constraining design decisions of optparse, this wasn't really +possible. Some of the problems included: + +* The optparse module exposes the internals of its parsing algorithm. + In particular, ``parser.largs`` and ``parser.rargs`` are guaranteed + to be available to callbacks [11]_. This makes it extremely + difficult to improve the parsing algorithm as was necessary in + argparse for proper handling of positional arguments and variable + length arguments. For example, ``nargs='+'`` in argparse is matched + using regular expressions and thus has no notion of things like + ``parser.largs``. + +* The optparse extension APIs are extremely complex. For example, + just to use a simple custom string-to-object conversion function, + you have to subclass ``Option``, hack class attributes, and then + specify your custom option type to the parser, like this:: + + class MyOption(Option): + TYPES = Option.TYPES + ("mytype",) + TYPE_CHECKER = copy(Option.TYPE_CHECKER) + TYPE_CHECKER["mytype"] = check_mytype + parser = optparse.OptionParser(option_class=MyOption) + parser.add_option("-m", type="mytype") + + For comparison, argparse simply allows conversion functions to be + used as ``type=`` arguments directly, e.g.:: + + parser = argparse.ArgumentParser() + parser.add_option("-m", type=check_mytype) + + But given the baroque customization APIs of optparse, it is unclear + how such a feature should interact with those APIs, and it is + quite possible that introducing the simple argparse API would break + existing custom Option code. + +* Both optparse and argparse parse command line arguments and assign + them as attributes to an object returned by ``parse_args``. + However, the optparse module guarantees that the ``take_action`` + method of custom actions will always be passed a ``values`` object + which provides an ``ensure_value`` method [12]_, while the argparse + module allows attributes to be assigned to any object, e.g.:: + + foo_object = ... + parser.parse_args(namespace=foo_object) + foo_object.some_attribute_parsed_from_command_line + + Modifying optparse to allow any object to be passed in would be + difficult because simply passing the ``foo_object`` around instead + of a ``Values`` instance will break existing custom actions that + depend on the ``ensure_value`` method. + +Because of issues like these, which made it unreasonably difficult +for argparse to stay compatible with the optparse APIs, argparse was +developed as an independent module. Given these issues, merging all +the argparse features into optparse with no backwards +incompatibilities seems unlikely. + + +Deprecation of getopt and optparse +================================== +There is still some debate over the best way (if at all) to encourage +users to move from getopt and optparse to their replacement, +argparse. The current recommendation of this PEP is the following +conservative deprecation strategy: + +* Python 3.2, Python 2.7 and any later Python 2.X releases -- + PendingDeprecation warnings, which by default are not displayed, + and documentation notes directing users of getopt and optparse to + argparse. + +* Python 3.3 -- Same as above + +* Python 3.4 -- Deprecation warnings for getopt and optparse, which + by default *are* displayed. + +Though this is slower than the usual deprecation process, it seems +prudent to avoid producing any casually visible Deprecation warnings +until Python 3.X has had some additional time to attract developers. + + +Open Issues +=========== +The argparse module supports Python from 2.3 up through 3.2 and as a +result relies on traditional ``%(foo)s`` style string formatting. It +has been suggested that it might be better to use the new style +``{foo}`` string formatting [13]_. This seems like a good idea, but +would break backwards compatibility for existing argparse-based +scripts unless we can come up with a way to reasonably support both +syntaxes. + + +References +========== +.. [1] argparse + (http://code.google.com/p/argparse/) + +.. [2] getopt + (http://docs.python.org/library/getopt.html) + +.. [3] optparse + (http://docs.python.org/library/optparse.html) + +.. [4] argparse in IPython + (http://mail.scipy.org/pipermail/ipython-dev/2009-April/005102.html) + +.. [5] argparse in Debian + (http://packages.debian.org/search?keywords=python-argparse) + +.. [6] 2007-01-03 request for argparse in the standard library + (http://mail.python.org/pipermail/python-list/2007-January/592646.html) + +.. [7] 2009-06-09 request for argparse in the standard library + (http://bugs.python.org/issue6247) + +.. [8] 2009-09-10 request for argparse in the standard library + (http://mail.python.org/pipermail/stdlib-sig/2009-September/000342.html) + +.. [9] Fredrik Lundh response to [6]_ + (http://mail.python.org/pipermail/python-list/2007-January/592675.html) + +.. [10] optparse variable args + (http://docs.python.org/library/optparse.html#callback-example-6-variable-ar…) + +.. [11] parser.largs and parser.rargs + (http://docs.python.org/library/optparse.html#how-callbacks-are-called) + +.. [12] take_action values argument + (http://docs.python.org/library/optparse.html#adding-new-actions) + +.. [13] use {}-formatting instead of %-formatting + (http://bugs.python.org/msg89279) + + +Copyright +========= +This document has been placed in the public domain. + + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 70 + coding: utf-8 + End:

1 0

r75096 - peps/trunk/pep-3144.txt
by brett.cannon 27 Sep '09

27 Sep '09

Author: brett.cannon Date: Sun Sep 27 21:38:05 2009 New Revision: 75096 Log: Update from Peter Moody. Modified: peps/trunk/pep-3144.txt Modified: peps/trunk/pep-3144.txt ============================================================================== --- peps/trunk/pep-3144.txt (original) +++ peps/trunk/pep-3144.txt Sun Sep 27 21:38:05 2009 @@ -31,40 +31,63 @@ Rationale: - - ipaddr was designed with the goal of abstracting out as much of the common - functionality as possible. As mentioned earlier, the similarities between - addresses and networks, IPV6 and IPV4 allows much code to be reused since - python allows for easy (and clean) multiple inheritance. Methods which are - specific to IPV4 or IPV6, addresses or networks are inherited from - appropriately named classes (Basev4, Basev6, BaseNet, BaseIP, etc) to - provide the full functionality of IPv4Address, IPv4Network, IPv6Address and - IPv6Network. + ipaddr was designed with a few basic principals in mind: + + - IPv4 and IPv6 objects are distinct. + - IP addresses and IP networks are distinct. + - the library should be useful and the assumptions obvious to the network + programmer. + - IP networks should be treated as lists (as opposed to some other + python intrinsic) in so far as it makes sense. + - the library should be lightweight and fast without sacrificing + expected functionality. + - Distinct IPV4 and IPV6 objects. While there are many similarities, IPV4 and IPV6 objects are fundamentally different. The similarities allow for easy abstraction of certain operations which affect the bits from both in the same manner, but their - differences mean attempts to combine them into one object would be like - trying to force a round peg into a square hole (or visa versa). + differences mean attempts to combine them into one object yield unexpected + results. According to Vint Cerf, "I have seen a substantial amount of + traffic about IPv4 and IPv6 comparisons and the general consensus is that + these are not comparable." (Vint Cerf [2]). For python versions >= 3.0, + this means that (<, >, <=, >=) comparison operations between IPv4 and IPv6 + objects raise a TypeError per the Ordering Comparisons [3]. - Distinct network and address objects. - Many people think of IP addresses and IP networks as synonymous, while they - are however, distinct. An IPV4 address is a single 32 bit number while the - IPV4 address assigned to a networked computer is a 32 bit address and - associated network. Similarly, an IPV6 address is a 128 bit number while - an IPV6 address assigned to a networked computer is a 128 bit number and - associated network information. The similarities leads to easy abstraction - of some methods and properties, but there are obviously a number of - address/network specific properties which require they be distinct. For - instance, IP networks contain network address (the base address of the - network), broadcast addresses (the upper end of the network, also the - address to which every machine on a given network is supposed listen, hence - the name broadcast), supernetworks and subnetworks, etc. The individual - property addresses in an IP network obviously don't have the same - properties, they're simply 32 or 128 bit numbers. + An IPV4 address is a single 32 bit number while the IPV4 address assigned + to a networked computer is a 32 bit address and associated network. + Similarly, an IPV6 address is a 128 bit number while an IPV6 address + assigned to a networked computer is a 128 bit number and associated network + information. The similarities leads to easy abstraction of some methods + and properties, but there are obviously a number of address/network + specific properties which require they be distinct. For instance, IP + networks contain a network address (the base address of the network), + broadcast address (the upper end of the network, also the address to + which every machine on a given network is supposed listen, hence the name + broadcast), supernetworks and subnetworks, etc. The individual property + addresses in an IP network obviously don't have the same properties, + they're simply 32 or 128 bit numbers. + + - Principal of least confusion for network programmers. + + It should be understood that, above all, this module is designed with the + network administrator in mind. In practice, this means that a number of + assumptions are made with regards to common usage and the library prefers + the usefulness of accepted practice over strict adherence to RFCs. For + example, ipaddr accepts '192.168.1.1/24' as a network definition because + this is a very common way of describing an address + netmask despite the + fact that 192.168.1.1 is actually an IP address on the network + 192.168.1.0/24. Strict adherence would require that networks have all of + the host bits masked to zero, which would require two objects to describe + that IP + network. In practice, a looser interpretation of a network is + a very useful if common abstraction, so ipaddr prefers to make this + available. For the developer who is concerned with strict adherence, + ipaddr provides an optional 'strict' boolean argument to the + IPv(4|6)Network constructors which guarantees that all host bits are masked + down. - Treat network elements as lists (in so far as it's possible). @@ -84,7 +107,7 @@ While some network programmers will undoubtedly want more than this library provides, keeping the functionality to strictly what's required from a IP address manipulation module is critical to keeping the code fast, easily - comprehensible and extensible. I've tried to provide enough options in + comprehensible and extensible. It is a goal to provide enough options in terms of functionality to allow the developer to easily do their work without needlessly cluttering the library. Finally, It's important to note that this design doesn't prevent subclassing or otherwise extending to meet @@ -114,15 +137,15 @@ addresses and networks, both IPv4 and IPv6. In short, there is common functionality shared between (ipaddr class names in parentheses): - 1. all IP addresses and networks, both IPv4 and IPv6. (IPAddrBase) + 1. all IP addresses and networks, both IPv4 and IPv6. (_IPAddrBase) - 2. all IP addresses of both versions. (BaseIP) + 2. all IP addresses of both versions. (_BaseIP) - 3. all IP networks of both version. (BaseNet) + 3. all IP networks of both version. (_BaseNet) - 4. all IPv4 objects, both addresses and networks. (BaseV4) + 4. all IPv4 objects, both addresses and networks. (_BaseV4) - 5. all IPv6 objects, both addresses and networks. (BaseV6) + 5. all IPv6 objects, both addresses and networks. (_BaseV6) Seeing this as a clear hierarchy is important for recognizing how much code is common between the four main classes. For this reason, ipaddr uses @@ -137,9 +160,9 @@ might guess, return the appropriately typed address or network objects for the given argument. - Finally, there is no meaningful natural ordering between IPv4 and IPv6 - addresses ("these protocols are ships-in-the-night"), so rather than invent - a standard, ipaddr follows Ordering Comparisons [2] and returns a TypeError + Finally, as mentioned earlier, there is no meaningful natural ordering + between IPv4 and IPv6 addresses and networks [2]. Rather than invent a + standard, ipaddr follows Ordering Comparisons and returns a TypeError when asked to compare objects of differing IP versions. In practice, there are many ways a programmer may wish to order the addresses, so this this shouldn't pose a problem for the developer who can easily write: @@ -167,7 +190,9 @@ In [1]: IPNetwork('1.1.1.1').with_hostmask Out[1]: '1.1.1.1/0.0.0.0' - the same applies to IPv6 + the same applies to IPv6. It should be noted that netmasks and hostmasks + are not commonly used in IPv6, the methods exist for compatibility with + IPv4. - Lazy evaluation combined with aggressive caching of network elements. @@ -308,17 +333,49 @@ (the same methods exist for IPv4 networks and addresses, but they're just stubs for returning the normal __str__ representation). + - Most other common operations. + + It is a design goal to support all of the common operation expected from + an IP address manipulation module. As such, finding supernets, subnets, + address and network containment etc are all supported. Reference Implementation: A reference implementation is available at: - http://ipaddr-py.googlecode.com/svn/branches/2.0.x + http://ipaddr-py.googlecode.com/svn/trunk References: [1] http://bugs.python.org/issue3959 - [2] http://docs.python.org/dev/3.0/whatsnew/3.0.html#ordering-comparisons + [2] Appealing to authority is a logical fallacy, but Vint Cerf is an + an authority who can't be ignored. Full text of the email follows: + + """ + I have seen a substantial amount of traffic about IPv4 and IPv6 + comparisons and the general consensus is that these are not comparable. + + If we were to take a very simple minded view, we might treat these as + pure integers in which case there is an ordering but not a useful one. + + In the IPv4 world, "length" is important because we take longest (most + specific) address first for routing. Length is determine by the mask, + as you know. + + Assuming that the same style of argument works in IPv6, we would have + to conclude that treating an IPv6 value purely as an integer for + comparison with IPv4 would lead to some really strange results. + + All of IPv4 space would lie in the host space of 0::0/96 prefix of + IPv6. For any useful interpretation of IPv4, this is a non-starter. + + I think the only sensible conclusion is that IPv4 values and IPv6 values + should be treated as non-comparable. + + Vint + """ + + [3] http://docs.python.org/dev/3.0/whatsnew/3.0.html#ordering-comparisons Copyright:

1 0

r75095 - python/trunk/Lib/unittest/main.py
by michael.foord 27 Sep '09

27 Sep '09

Author: michael.foord Date: Sun Sep 27 21:15:41 2009 New Revision: 75095 Log: Test creation moved from TestProgram.parseArgs to TestProgram.createTests exclusively. Issue 6956. Modified: python/trunk/Lib/unittest/main.py Modified: python/trunk/Lib/unittest/main.py ============================================================================== --- python/trunk/Lib/unittest/main.py (original) +++ python/trunk/Lib/unittest/main.py Sun Sep 27 21:15:41 2009 @@ -109,9 +109,9 @@ if opt in ('-v','--verbose'): self.verbosity = 2 if len(args) == 0 and self.defaultTest is None: - self.test = self.testLoader.loadTestsFromModule(self.module) - return - if len(args) > 0: + # createTests will load tests from self.module + self.testNames = None + elif len(args) > 0: self.testNames = args if __name__ == '__main__': # to support python -m unittest ... @@ -123,8 +123,11 @@ self.usageExit(msg) def createTests(self): - self.test = self.testLoader.loadTestsFromNames(self.testNames, - self.module) + if self.testNames is None: + self.test = self.testLoader.loadTestsFromModule(self.module) + else: + self.test = self.testLoader.loadTestsFromNames(self.testNames, + self.module) def _do_discovery(self, argv, Loader=loader.TestLoader): # handle command line args for test discovery

1 0

r75094 - in python/branches/release31-maint: Doc/whatsnew/3.0.rst
by benjamin.peterson 27 Sep '09

27 Sep '09

Author: benjamin.peterson Date: Sun Sep 27 18:42:15 2009 New Revision: 75094 Log: Merged revisions 75090 via svnmerge from svn+ssh://pythondev@svn.python.org/python/branches/py3k ........ r75090 | benjamin.peterson | 2009-09-27 11:32:56 -0500 (Sun, 27 Sep 2009) | 1 line use more correct callable replacement ........ Modified: python/branches/release31-maint/ (props changed) python/branches/release31-maint/Doc/whatsnew/3.0.rst Modified: python/branches/release31-maint/Doc/whatsnew/3.0.rst ============================================================================== --- python/branches/release31-maint/Doc/whatsnew/3.0.rst (original) +++ python/branches/release31-maint/Doc/whatsnew/3.0.rst Sun Sep 27 18:42:15 2009 @@ -804,8 +804,8 @@ ``f(*args)``. * Removed :func:`callable`. Instead of ``callable(f)`` you can use - ``hasattr(f, '__call__')``. The :func:`operator.isCallable` function - is also gone. + ``hasattr(type(f), '__call__')``. The :func:`operator.isCallable` function is + also gone. * Removed :func:`coerce`. This function no longer serves a purpose now that classic classes are gone.

1 0

r75093 - python/branches/py3k
by mark.dickinson 27 Sep '09

27 Sep '09

Author: mark.dickinson Date: Sun Sep 27 18:41:06 2009 New Revision: 75093 Log: Blocked revisions 75091 via svnmerge ........ r75091 | mark.dickinson | 2009-09-27 17:39:28 +0100 (Sun, 27 Sep 2009) | 1 line Eliminate unnecessary get_wrapped_(u)long defines in struct module. ........ Modified: python/branches/py3k/ (props changed)

1 0

r75092 - python/branches/release26-maint
by mark.dickinson 27 Sep '09

27 Sep '09

Author: mark.dickinson Date: Sun Sep 27 18:40:34 2009 New Revision: 75092 Log: Blocked revisions 75091 via svnmerge ........ r75091 | mark.dickinson | 2009-09-27 17:39:28 +0100 (Sun, 27 Sep 2009) | 1 line Eliminate unnecessary get_wrapped_(u)long defines in struct module. ........ Modified: python/branches/release26-maint/ (props changed)

1 0

r75091 - python/trunk/Modules/_struct.c
by mark.dickinson 27 Sep '09

27 Sep '09

Author: mark.dickinson Date: Sun Sep 27 18:39:28 2009 New Revision: 75091 Log: Eliminate unnecessary get_wrapped_(u)long defines in struct module. Modified: python/trunk/Modules/_struct.c Modified: python/trunk/Modules/_struct.c ============================================================================== --- python/trunk/Modules/_struct.c (original) +++ python/trunk/Modules/_struct.c Sun Sep 27 18:39:28 2009 @@ -213,9 +213,6 @@ #endif -#define get_wrapped_long get_long -#define get_wrapped_ulong get_ulong - /* Floating point helpers */ static PyObject * @@ -525,7 +522,7 @@ { unsigned long x; unsigned int y; - if (get_wrapped_ulong(v, &x) < 0) + if (get_ulong(v, &x) < 0) return -1; y = (unsigned int)x; #if (SIZEOF_LONG > SIZEOF_INT) @@ -550,7 +547,7 @@ np_ulong(char *p, PyObject *v, const formatdef *f) { unsigned long x; - if (get_wrapped_ulong(v, &x) < 0) + if (get_ulong(v, &x) < 0) return -1; memcpy(p, (char *)&x, sizeof x); return 0; @@ -757,7 +754,7 @@ { long x; Py_ssize_t i; - if (get_wrapped_long(v, &x) < 0) + if (get_long(v, &x) < 0) return -1; i = f->size; if (i != SIZEOF_LONG) { @@ -780,7 +777,7 @@ { unsigned long x; Py_ssize_t i; - if (get_wrapped_ulong(v, &x) < 0) + if (get_ulong(v, &x) < 0) return -1; i = f->size; if (i != SIZEOF_LONG) { @@ -975,7 +972,7 @@ { long x; Py_ssize_t i; - if (get_wrapped_long(v, &x) < 0) + if (get_long(v, &x) < 0) return -1; i = f->size; if (i != SIZEOF_LONG) { @@ -998,7 +995,7 @@ { unsigned long x; Py_ssize_t i; - if (get_wrapped_ulong(v, &x) < 0) + if (get_ulong(v, &x) < 0) return -1; i = f->size; if (i != SIZEOF_LONG) {

1 0

r75090 - python/branches/py3k/Doc/whatsnew/3.0.rst
by benjamin.peterson 27 Sep '09

27 Sep '09

Author: benjamin.peterson Date: Sun Sep 27 18:32:56 2009 New Revision: 75090 Log: use more correct callable replacement Modified: python/branches/py3k/Doc/whatsnew/3.0.rst Modified: python/branches/py3k/Doc/whatsnew/3.0.rst ============================================================================== --- python/branches/py3k/Doc/whatsnew/3.0.rst (original) +++ python/branches/py3k/Doc/whatsnew/3.0.rst Sun Sep 27 18:32:56 2009 @@ -804,8 +804,8 @@ ``f(*args)``. * Removed :func:`callable`. Instead of ``callable(f)`` you can use - ``hasattr(f, '__call__')``. The :func:`operator.isCallable` function - is also gone. + ``hasattr(type(f), '__call__')``. The :func:`operator.isCallable` function is + also gone. * Removed :func:`coerce`. This function no longer serves a purpose now that classic classes are gone.

1 0