| msg58511 - (view) |
Author: Christian Heimes (christian.heimes) *  |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2010-09-18 16:33 |
| I'm still against collecting all types in one module. Closing. |
|
|