classification
Title: Semi autogenerated _types module
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 3.2
process
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, benjamin.peterson, christian.heimes, gvanrossum, pitrou
Priority: low Keywords: patch

Created on 2007-12-13 01:40 by christian.heimes, last changed 2010-09-18 16:33 by gvanrossum. This issue is now closed.

Files
File name Uploaded Description Edit
py3k_autogen_types.patch christian.heimes, 2007-12-13 01:40
unnamed benjamin.peterson, 2008-03-22 13:18
Messages (13)
msg58511 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-12-13 01:40
A while ago I've experimented with the pyvm module and a semi
auto-generated types list. The patch adds a script that reads
Include/*.h and adds all available PyTypeObjects to Modules/_typesmodule.c.

The patch or script may be useful in the future.
msg58515 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2007-12-13 02:11
But what about static type objects that nevertheless may be exposed to
Python (e.g. dict_keyview?).
msg58517 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-12-13 02:15
Guido van Rossum wrote:
> But what about static type objects that nevertheless may be exposed to
> Python (e.g. dict_keyview?).

I took care of the views a few weeks ago when I added all views and
iterators to the header files.

['PyCObject',
 'bool',
 'builtin_function_or_method',
 'bytearray',
 'bytearray_iterator',
 'bytes',
 'bytes_iterator',
 'callable_iterator',
 'cell',
 'classmethod',
 'classmethod_descriptor',
 'cmpwrapper',
 'code',
 'complex',
 'dict',
 'dict_itemiterator',
 'dict_items',
 'dict_keyiterator',
 'dict_keys',
 'dict_proxy',
 'dict_valueiterator',
 'dict_values',
 'enumerate',
 'float',
 'frame',
 'frozenset',
 'function',
 'generator',
 'getset_descriptor',
 'imp.NullImporter',
 'instancemethod',
 'int',
 'iterator',
 'list',
 'list_iterator',
 'list_reverseiterator',
 'longrange_iterator',
 'member_descriptor',
 'memoryview',
 'method',
 'method_descriptor',
 'module',
 'object',
 'property',
 'range',
 'range_iterator',
 'reversed',
 'set',
 'set_iterator',
 'slice',
 'sortwrapper',
 'staticmethod',
 'stderrprinter',
 'str',
 'str_iterator',
 'super',
 'traceback',
 'tuple',
 'tuple_iterator',
 'type',
 'wrapper_descriptor',
 'zip_iterator']
msg64283 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-03-21 21:24
I think this is a really good idea. It's in stride with DRY, clean, and
sure beats the Python acrobatics that types currently does to find them.
msg64284 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-03-21 21:32
I'm still resounding -1 on this.

Grouping types together because they happen to be implemented in C is a
silly thing to do.  Groupings should be based on usage, not on
implementation style.  I successfully argued against the inclusion of
all metaclasses in the abc.py module.  This proposal would be even more
wrong.  You might as well insist that all decorators need to be placed
in one module.
msg64286 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-03-21 22:03
Okay. How about we use this like it is for 2.x, and split it out into
different modules in Py3k. We could have execution_types and core_types.
msg64289 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-03-21 22:27
On Fri, Mar 21, 2008 at 3:03 PM, Benjamin Peterson
<report@bugs.python.org> wrote:
>
>  Benjamin Peterson <musiccomposition@gmail.com> added the comment:
>
>  Okay. How about we use this like it is for 2.x, and split it out into
>  different modules in Py3k. We could have execution_types and core_types.

No.
msg64290 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-03-21 22:32
> No
Well, okay. I still think we should expose these core interpreter types
somehow, so people can identify types easily. I don't want to be forced
to finding the type of sys._getframe to tell if I have a frame object on
my hands. Where would you put them?
msg64315 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-03-22 04:06
>  Well, okay. I still think we should expose these core interpreter types
>  somehow, so people can identify types easily. I don't want to be forced
>  to finding the type of sys._getframe to tell if I have a frame object on
>  my hands. Where would you put them?

Perhaps that one belongs together with sys._getframe?

You don't seem to be getting my point (or you are purposely ignoring
it), and this is frustrating for me. If these types must be exposed
they should be each be exposed in a a module (new or existing) that
defines other objects (types, functions, constants, what have you)
with a related purpose. So maybe dict views etc. can be in
collections. And maybe module, function, class, properties, some
standard decorators (classmethod, staticmethod) and various types of
methods and method wrappers can be in a module that packages code
structures. OTOH code, frame, traceback may be more suitable for a
low-level module (although I'm not sure about traceback, perhaps it is
closer exceptions). Many types of iterators may best be placed in
itertools (which defines them in the first place, many operations
there already *are* their own type). But the iterators over the
built-in collection types (list, dict etc.) should probably live in
collections again.

You see, coming up with a meaningful grouping is not all that easy --
but that's no reason to lump them all together in a "built-in-types"
module. Another criterion for grouping is whether the types make sense
for other implementations like Jython, IronPython or PyPy, or not.

I'm all for exposing these. But I'm 100% against just collecting all
those types and putting them in a single grab-bag module.
msg64321 - (view) Author: Benjamin Peterson (benjamin.peterson) * (Python committer) Date: 2008-03-22 13:18
On Fri, Mar 21, 2008 at 11:06 PM, Guido van Rossum <report@bugs.python.org>
wrote:

>
> Guido van Rossum <guido@python.org> added the comment:
>
> >  Well, okay. I still think we should expose these core interpreter types
> >  somehow, so people can identify types easily. I don't want to be forced
> >  to finding the type of sys._getframe to tell if I have a frame object
> on
> >  my hands. Where would you put them?
>
> Perhaps that one belongs together with sys._getframe?
>
> You don't seem to be getting my point (or you are purposely ignoring
> it), and this is frustrating for me. If these types must be exposed
> they should be each be exposed in a a module (new or existing) that
> defines other objects (types, functions, constants, what have you)
> with a related purpose. So maybe dict views etc. can be in
> collections. And maybe module, function, class, properties, some
> standard decorators (classmethod, staticmethod) and various types of
> methods and method wrappers can be in a module that packages code
> structures. OTOH code, frame, traceback may be more suitable for a
> low-level module (although I'm not sure about traceback, perhaps it is
> closer exceptions). Many types of iterators may best be placed in
> itertools (which defines them in the first place, many operations
> there already *are* their own type). But the iterators over the
> built-in collection types (list, dict etc.) should probably live in
> collections again.

I understand your point; I just didn't understand the extent that you want
to go to.

>
>
> You see, coming up with a meaningful grouping is not all that easy --
> but that's no reason to lump them all together in a "built-in-types"
> module. Another criterion for grouping is whether the types make sense
> for other implementations like Jython, IronPython or PyPy, or not.

It is indeed hard.

>
>
> I'm all for exposing these. But I'm 100% against just collecting all
> those types and putting them in a single grab-bag module.
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1605>
> __________________________________
>
msg116802 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-09-18 15:44
Is this ever likely to go anywhere?  My understanding is that this would be difficult to do (or have I simply misread something?).  If I'm correct, wouldn't it be better to use our limited resources elsewhere?
msg116809 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-09-18 16:18
Well, the core issue is a disagreement on the way to go.

I would agree with Benjamin's and Christian's proposal, given that it's quite practical to implement. Guido's proposal means we would have to add new modules just so that the relevant C types can be exposed "at the right place".

The types module is generally used for low-level trickery (since most useful types are accessible from the builtin namespace), and IMO it makes sense to have a dedicated module for that.
msg116811 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2010-09-18 16:33
I'm still against collecting all types in one module. Closing.
History
Date User Action Args
2010-09-18 16:33:38gvanrossumsetstatus: open -> closed

messages: + msg116811
2010-09-18 16:18:09pitrousetnosy: + pitrou
messages: + msg116809
2010-09-18 15:44:50BreamoreBoysetnosy: + BreamoreBoy
messages: + msg116802
2010-08-07 20:45:56terry.reedysetversions: + Python 3.2, - Python 2.6, Python 3.0
2008-03-22 13:18:41benjamin.petersonsetfiles: + unnamed
messages: + msg64321
2008-03-22 04:06:28gvanrossumsetmessages: + msg64315
2008-03-21 22:32:48benjamin.petersonsetmessages: + msg64290
2008-03-21 22:27:18gvanrossumsetmessages: + msg64289
2008-03-21 22:03:03benjamin.petersonsetmessages: + msg64286
2008-03-21 21:32:08gvanrossumsetmessages: + msg64284
2008-03-21 21:24:54benjamin.petersonsetnosy: + benjamin.peterson
messages: + msg64283
2008-01-06 22:29:44adminsetkeywords: - py3k
versions: Python 2.6, Python 3.0
2007-12-13 02:15:15christian.heimessetmessages: + msg58517
2007-12-13 02:11:04gvanrossumsetnosy: + gvanrossum
messages: + msg58515
2007-12-13 01:40:11christian.heimescreate