Benjamin Peterson <[EMAIL PROTECTED]> added the comment:
On Fri, Mar 21, 2008 at 11:06 PM, Guido van Rossum <[EMAIL PROTECTED]>
wrote:
>
> Guido van Rossum <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1605>
> __________________________________
>
Added file: http://bugs.python.org/file9810/unnamed
__________________________________
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1605>
__________________________________
<br><br><div class="gmail_quote">On Fri, Mar 21, 2008 at 11:06 PM, Guido van
Rossum <<a href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>>
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Guido van Rossum <<a href="mailto:[EMAIL PROTECTED]">[EMAIL
PROTECTED]</a>> added the comment:<br>
<br>
> Well, okay. I still think we should expose these core interpreter
types<br>
> somehow, so people can identify types easily. I don't want to be
forced<br>
> to finding the type of sys._getframe to tell if I have a frame
object on<br>
> my hands. Where would you put them?<br>
<br>
Perhaps that one belongs together with sys._getframe?<br>
<br>
You don't seem to be getting my point (or you are purposely ignoring<br>
it), and this is frustrating for me. If these types must be exposed<br>
they should be each be exposed in a a module (new or existing) that<br>
defines other objects (types, functions, constants, what have you)<br>
with a related purpose. So maybe dict views etc. can be in<br>
collections. And maybe module, function, class, properties, some<br>
standard decorators (classmethod, staticmethod) and various types of<br>
methods and method wrappers can be in a module that packages code<br>
structures. OTOH code, frame, traceback may be more suitable for a<br>
low-level module (although I'm not sure about traceback, perhaps it is<br>
closer exceptions). Many types of iterators may best be placed in<br>
itertools (which defines them in the first place, many operations<br>
there already *are* their own type). But the iterators over the<br>
built-in collection types (list, dict etc.) should probably live in<br>
collections again.</blockquote><div>I understand your point; I just didn't
understand the extent that you want to go to.<br></div><blockquote
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin:
0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
You see, coming up with a meaningful grouping is not all that easy --<br>
but that's no reason to lump them all together in a
"built-in-types"<br>
module. Another criterion for grouping is whether the types make sense<br>
for other implementations like Jython, IronPython or PyPy, or
not.</blockquote><div>It is indeed hard.<br></div><blockquote
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin:
0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
I'm all for exposing these. But I'm 100% against just collecting all<br>
those types and putting them in a single grab-bag module.<br>
<br>
__________________________________<br>
Tracker <<a href="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</a>><br>
<<a href="http://bugs.python.org/issue1605";
target="_blank">http://bugs.python.org/issue1605</a>><br>
__________________________________<br>
</blockquote></div><br>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
