On 23 May 2002, Martin v. Loewis wrote:
> Kevin Jacobs <jacobs@penguin.theopalgroup.com> writes:
> > Pointless semantic arguments aside, I agree with Skip. I don't care how
> > many other ways we provide to spell types: until the types module is
> > depricated, I do not see why it should be intentionally broken by not
> > covering all builtin types (unless thus breaking the module is a slimy way
> > of encouraging its deprication, in which case I will object on procedural
> > grounds).
>
> Nobody suggested to break the types module; not adding BooleanType
> would not break it.
http://www.python.org/doc/current/lib/module-types.html:
3.6 types -- Names for ALL built-in types
This module defines names for ALL object types that are used by the
standard Python interpreter, but not for the types defined by various
extension modules.
How much clearer does it need to be?
Further, the expectation of real-live Python users is that it will contain
the boolean type. This is not an academic argument for me, and likely for
many others. We have large code bases that use the types module, and expect
the module to rigorously track new types until something better is fully
implemented, stable, and the old module is properly depricated.
I still can't believe we have nothing better to do than argue about this
spectacularly piddly issue. If you don't like Skip's patch, then stick your
fingers in your ears and humm real loud -- just pretend it isn't there -- it
costs absolutely nothing to those who won't be using it.
Ate two bowls of cranky flakes this morning,
-Kevin
--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19 E-mail: jacobs@theopalgroup.com
Fax: (216) 986-0714 WWW: http://www.theopalgroup.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4