What's up with site.Quitter?

[James Stroud]

Hello All,

Still jubilantly configuring my work environment for python 2.5, I came
accross a curiosity when writing an automatic vim syntax file creator
(so I can automatically update my syntax coloring with future python
releases).

It seems I can find a reference to just about every type except those
for "exit" and "quit" in the standard library somewhere. E.g.:

py> type(__builtins__.Ellipsis) is types.EllipsisType
True

However, in an appearant break with consistency, this can not be done
for "exit" and "quit" because site.Quitter is nested inside of the
setquit() function in the site.py module.

Would moving this class definition to module level be something that
would meet with great resistance?

I was thinking of posting to python-dev, but that list looked pretty
high-level.

James

--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

 

[Fredrik Lundh]

It seems I can find a reference to just about every type except those
for "exit" and "quit" in the standard library somewhere. E.g.:

py> type(__builtins__.Ellipsis) is types.EllipsisType
True

However, in an appearant break with consistency, this can not be done
for "exit" and "quit" because site.Quitter is nested inside of the
setquit() function in the site.py module.

consistency with what?

the exact implementation of "quit" and "exit" is implementation and
version dependent; if you need the type, use type(quit) and type(exit),
respectively.

</F>

 

[James Stroud]

consistency with what?

The rest of the __builtins__.

the exact implementation of "quit" and "exit" is implementation and
version dependent; if you need the type, use type(quit) and type(exit),
respectively.

Yes, but I was speaking more consistency than convenience (see above for
what I mean by consistency).

James


--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

 

[Fredrik Lundh]

Yes, but I was speaking more consistency than convenience (see above for
what I mean by consistency).

why would having access to a type object for exit/quit help you do
proper syntax coloring, btw? if you want to generate a syntax table,
wouldn't it be better to use things like

issubclass(obj, Exception)

and

callable(obj)

etc. ?

(__builtins__ is an implementation detail, btw; if you want a list of
the builtins, import __builtin__ (no plural) and do dir on that).

</F>

 

[Georg Brandl]

Hello All,

Still jubilantly configuring my work environment for python 2.5, I came
accross a curiosity when writing an automatic vim syntax file creator
(so I can automatically update my syntax coloring with future python
releases).

It seems I can find a reference to just about every type except those
for "exit" and "quit" in the standard library somewhere. E.g.:

py> type(__builtins__.Ellipsis) is types.EllipsisType
True

However, in an appearant break with consistency, this can not be done
for "exit" and "quit" because site.Quitter is nested inside of the
setquit() function in the site.py module.

Would moving this class definition to module level be something that
would meet with great resistance?

Not really, but what would you do with it? It's an internal object used
for only exit() and quit(), and of no real use elsewhere.

Georg

 

[James Stroud]

why would having access to a type object for exit/quit help you do
proper syntax coloring, btw? if you want to generate a syntax table,
wouldn't it be better to use things like

issubclass(obj, Exception)

and

callable(obj)

etc. ?

Actually, my code has the first test and the second is a consequence of
my checking for types.BuiltinFunctionType. Perhaps the way you suggest
is less cumbersome. Food for thought.

(__builtins__ is an implementation detail, btw;

OK. I assumed that __builtins__ are somehow sacred regarding what would
be reserved. Perhaps not. However, I used __builtins__ to generate a
list of reserved words and used types for syntax checking.

> if you want a list of
> the builtins, import __builtin__ (no plural) and do dir on that).
>
> </F>

cPython, at least, gives this equivalence:

py> import __builtin__
py> __builtins__ is __builtin__
True

I assume, as you suggest, that one may not depend on this equivalence
for all implementations.

Thank you for your suggestions,
James

 

[skip]

Georg> Not really, but what would you do with it? It's an internal
Georg> object used for only exit() and quit(), and of no real use
Georg> elsewhere.

In fact, I would argue that objects placed in builtins as a convenience in
inteactive mode shouldn't be colorized at all (dir, help, exit, quit,
copyright, credits, license, maybe vars). They shouldn't be considered
special in code written to be used in non-interactive contexts.

Skip

 

[James Stroud]

Not really, but what would you do with it? It's an internal object used
for only exit() and quit(), and of no real use elsewhere.

Georg

Outside of my type checking against it for syntax coloring, I have no
idea. I just get a funny feeling with computers when exceptions to a
general pattern come along. But then again, maybe the consistency I
perceive for the rest of __builtins__ is more or less illusory. This
might have been the point of Fredrik's question.

James

 

[skip]

James> But then again, maybe the consistency I perceive for the rest of
James> __builtins__ is more or less illusory. This might have been the
James> point of Fredrik's question.

As I implied in my note, there is a difference between fundamental builtins
like open and Exception, and convenience builtins like exit and license. If
you make that distinction and only really worry about consistency within the
fundamental builtins I think you'll be on more solid ground.

Skip

 

[James Stroud]

James> But then again, maybe the consistency I perceive for the rest of
James> __builtins__ is more or less illusory. This might have been the
James> point of Fredrik's question.

As I implied in my note, there is a difference between fundamental builtins
like open and Exception, and convenience builtins like exit and license. If
you make that distinction and only really worry about consistency within the
fundamental builtins I think you'll be on more solid ground.

Skip

Thank you. I'm glad I'm learning something from what originally felt
like a silly distraction (writing the syntax colorer generator).

James