Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #78746
| From | jakubo <jakubo@example.org> |
|---|---|
| Newsgroups | comp.lang.python |
| Subject | Re: Clearing globals in CPython |
| Date | 2014-10-06 09:05 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <m0tm0d$j39$1@speranza.aioe.org> (permalink) |
| References | <542c2527$0$13013$c3e8da3$5496439d@news.astraweb.com> <mailman.14526.1412184262.18130.python-list@python.org> |
On 2014-10-01, Peter Otten <__peter__@web.de> wrote: > Steven D'Aprano wrote: > >> Out of curiosity, I ran: >> >> globals().clear() >> >> Oops. >> >> So, with no built-ins available, import no longer works. That makes things >> rather tricky. >> >> Obviously the easiest way to recover is to exit the current session and >> restart it, but as a challenge, can we recover from this state? > > $ python3 > Python 3.4.0 (default, Apr 11 2014, 13:05:11) > [GCC 4.8.2] on linux > Type "help", "copyright", "credits" or "license" for more information. >>>> globals().clear() >>>> import that > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ImportError: __import__ not found >>>> object = 1 .__class__.__bases__[0] >>>> Quitter = [c for c in object.__subclasses__() if c.__name__ == > "Quitter"][0] >>>> __builtins__ = Quitter.__call__.__globals__["__builtins__"] >>>> import this > The Zen of Python, by Tim Peters > > Beautiful is better than ugly. > Explicit is better than implicit. > Simple is better than complex. > Complex is better than complicated. > Flat is better than nested. > Sparse is better than dense. > Readability counts. > Special cases aren't special enough to break the rules. > Although practicality beats purity. > Errors should never pass silently. > Unless explicitly silenced. > In the face of ambiguity, refuse the temptation to guess. > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're Dutch. > Now is better than never. > Although never is often better than *right* now. > If the implementation is hard to explain, it's a bad idea. > If the implementation is easy to explain, it may be a good idea. > Namespaces are one honking great idea -- let's do more of those! I have funnier one :) $ python3 Python 3.4.1 (default, Sep 10 2014, 22:21:18) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> globals().clear() >>> import this Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: __import__ not found >>> True.__ True.__abs__( True.__dir__( True.__format__( True.__init__( True.__mul__( True.__radd__( True.__rlshift__( True.__rshift__( True.__sub__( True.__add__( True.__divmod__( True.__ge__( True.__int__( True.__ne__( True.__rand__( True.__rmod__( True.__rsub__( True.__subclasshook__( True.__and__( True.__doc__ True.__getattribute__( True.__invert__( True.__neg__( True.__rdivmod__( True.__rmul__( True.__rtruediv__( True.__truediv__( True.__bool__( True.__eq__( True.__getnewargs__( True.__le__( True.__new__( True.__reduce__( True.__ror__( True.__rxor__( True.__trunc__( True.__ceil__( True.__float__( True.__gt__( True.__lshift__( True.__or__( True.__reduce_ex__( True.__round__( True.__setattr__( True.__xor__( True.__class__( True.__floor__( True.__hash__( True.__lt__( True.__pos__( True.__repr__( True.__rpow__( True.__sizeof__( True.__delattr__( True.__floordiv__( True.__index__( True.__mod__( True.__pow__( True.__rfloordiv__( True.__rrshift__( True.__str__( >>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those! >>> After invoking autocompletion (.__ and hitting tab), session has been automagically healed. -- jakubo
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Clearing globals in CPython Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-02 02:00 +1000
Re: Clearing globals in CPython Chris Angelico <rosuav@gmail.com> - 2014-10-02 02:14 +1000
Re: Clearing globals in CPython Chris Kaynor <ckaynor@zindagigames.com> - 2014-10-01 10:08 -0700
Re: Clearing globals in CPython Peter Otten <__peter__@web.de> - 2014-10-01 19:24 +0200
Re: Clearing globals in CPython Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-02 18:11 +1000
Re: Clearing globals in CPython Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-02 09:30 +0100
Re: Clearing globals in CPython jakubo <jakubo@example.org> - 2014-10-06 09:05 +0000
Re: Clearing globals in CPython Steven D'Aprano <steve@pearwood.info> - 2014-10-06 09:08 +0000
Re: Clearing globals in CPython Chris Angelico <rosuav@gmail.com> - 2014-10-06 20:30 +1100
Re: Clearing globals in CPython Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-10-01 19:17 +0100
Re: Clearing globals in CPython Terry Reedy <tjreedy@udel.edu> - 2014-10-01 14:44 -0400
Re: Clearing globals in CPython Marco Buttu <marco.buttu@gmail.com> - 2014-10-01 18:39 +0200
Re: Clearing globals in CPython Grant Edwards <invalid@invalid.invalid> - 2014-10-02 14:07 +0000
Re: Clearing globals in CPython Chris Angelico <rosuav@gmail.com> - 2014-10-03 00:12 +1000
Re: Clearing globals in CPython Stefan Behnel <stefan_ml@behnel.de> - 2014-10-03 07:26 +0200
csiph-web