Re: [stdlib-sig] [Python-3000] Types and classes
On 03/04/2008, Guido van Rossum guido@python.org wrote:
On Wed, Apr 2, 2008 at 4:45 PM, Paul Prescod paul@prescod.net wrote:
Also, could the types module be renamed "builtin_classes" or "core_classes" or something like that? It was always a weird name because it wasn't if it contained all of the types in a Python distribution. Just a set of core-to-the-implementation ones.
That's up to the stdlib reorg committee; my position has been for a long time that there shouldn't be a types module at all.
*If* it's to be renamed (which I have no strong opinion on) would making it sys.classes (or sys.types) be plausible? With the "sys = core" connotation, I find this better than an underscored name.
Paul.
On Thu, Apr 3, 2008 at 1:10 PM, Paul Moore p.f.moore@gmail.com wrote:
On 03/04/2008, Guido van Rossum guido@python.org wrote:
On Wed, Apr 2, 2008 at 4:45 PM, Paul Prescod paul@prescod.net wrote:
Also, could the types module be renamed "builtin_classes" or "core_classes" or something like that? It was always a weird name because it wasn't if it contained all of the types in a Python distribution. Just a set of core-to-the-implementation ones.
That's up to the stdlib reorg committee; my position has been for a long time that there shouldn't be a types module at all.
*If* it's to be renamed (which I have no strong opinion on) would making it sys.classes (or sys.types) be plausible? With the "sys = core" connotation, I find this better than an underscored name.
Not without taking a proper look at the sys module and how it should potentially be changed. It has become too much of a dumping ground for stuff in my opinion. There could definitely stand to be more of a separation between interpreter info and the current platform. Or even information versus changing what the interpreter can do.
But I am about to propose the removal of the 'types' module anyway, so I am not feeling very invested in this. =)
-Brett
participants (2)
-
Brett Cannon -
Paul Moore