builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
I try to compute the factorial of a large number with tail-recursion optimization decorator in Python3. The following code snippet is converted from the code snippet given here [1] by the following steps: $ pyenv shell datasci $ python --version Python 3.9.1 $ pip install 2to3 $ 2to3 -w this-script.py ``` # This program shows off a python decorator( # which implements tail call optimization. It # does this by throwing an exception if it is # its own grandparent, and catching such # exceptions to recall the stack. import sys class TailRecurseException: def __init__(self, args, kwargs): self.args = args self.kwargs = kwargs def tail_call_optimized(g): """ This function decorates a function with tail call optimization. It does this by throwing an exception if it is its own grandparent, and catching such exceptions to fake the tail call optimization. This function fails if the decorated function recurses in a non-tail context. """ def func(*args, **kwargs): f = sys._getframe() if f.f_back and f.f_back.f_back \ and f.f_back.f_back.f_code == f.f_code: raise TailRecurseException(args, kwargs) else: while 1: try: return g(*args, **kwargs) except TailRecurseException as e: args = e.args kwargs = e.kwargs func.__doc__ = g.__doc__ return func @tail_call_optimized def factorial(n, acc=1): "calculate a factorial" if n == 0: return acc return factorial(n-1, n*acc) print(factorial(1)) # prints a big, big number, # but doesn't hit the recursion limit. @tail_call_optimized def fib(i, current = 0, next = 1): if i == 0: return current else: return fib(i - 1, next, current + next) print(fib(1)) # also prints a big number, # but doesn't hit the recursion limit. ``` However, when I try to test the above script, the following error will be triggered: ``` $ python this-script.py Traceback (most recent call last): File "/home/werner/this-script.py", line 32, in func return g(*args, **kwargs) File "/home/werner/this-script.py", line 44, in factorial return factorial(n-1, n*acc) File "/home/werner/this-script.py", line 28, in func raise TailRecurseException(args, kwargs) TypeError: exceptions must derive from BaseException During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/werner/this-script.py", line 46, in print(factorial(1)) File "/home/werner/this-script.py", line 33, in func except TailRecurseException as e: TypeError: catching classes that do not inherit from BaseException is not allowed ``` Any hints for fixing this problem will be highly appreciated. [1] https://stackoverflow.com/q/27417874 Regards, HZ -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Thursday, December 30, 2021 at 9:04:36 PM UTC+8, [email protected] wrote: > I try to compute the factorial of a large number with tail-recursion > optimization decorator in Python3. The following code snippet is converted > from the code snippet given here [1] by the following steps: > > $ pyenv shell datasci > $ python --version > Python 3.9.1 > $ pip install 2to3 > $ 2to3 -w this-script.py > > ``` > # This program shows off a python decorator( > # which implements tail call optimization. It > # does this by throwing an exception if it is > # its own grandparent, and catching such > # exceptions to recall the stack. > > import sys > > class TailRecurseException: > def __init__(self, args, kwargs): > self.args = args > self.kwargs = kwargs > > def tail_call_optimized(g): > """ > This function decorates a function with tail call > optimization. It does this by throwing an exception > if it is its own grandparent, and catching such > exceptions to fake the tail call optimization. > > This function fails if the decorated > function recurses in a non-tail context. > """ > def func(*args, **kwargs): > f = sys._getframe() > if f.f_back and f.f_back.f_back \ > and f.f_back.f_back.f_code == f.f_code: > raise TailRecurseException(args, kwargs) > else: > while 1: > try: > return g(*args, **kwargs) > except TailRecurseException as e: > args = e.args > kwargs = e.kwargs > func.__doc__ = g.__doc__ > return func > > @tail_call_optimized > def factorial(n, acc=1): > "calculate a factorial" > if n == 0: > return acc > return factorial(n-1, n*acc) > > print(factorial(1)) > # prints a big, big number, > # but doesn't hit the recursion limit. > > @tail_call_optimized > def fib(i, current = 0, next = 1): > if i == 0: > return current > else: > return fib(i - 1, next, current + next) > > print(fib(1)) > # also prints a big number, > # but doesn't hit the recursion limit. > ``` > However, when I try to test the above script, the following error will be > triggered: > ``` > $ python this-script.py > Traceback (most recent call last): > File "/home/werner/this-script.py", line 32, in func > return g(*args, **kwargs) > File "/home/werner/this-script.py", line 44, in factorial > return factorial(n-1, n*acc) > File "/home/werner/this-script.py", line 28, in func > raise TailRecurseException(args, kwargs) > TypeError: exceptions must derive from BaseException > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "/home/werner/this-script.py", line 46, in > print(factorial(1)) > File "/home/werner/this-script.py", line 33, in func > except TailRecurseException as e: > TypeError: catching classes that do not inherit from BaseException is not > allowed > ``` > > Any hints for fixing this problem will be highly appreciated. See here [1] for the related discussion. [1] https://discuss.python.org/t/typeerror-catching-classes-that-do-not-inherit-from-baseexception-is-not-allowed/12800 HZ -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Fri, Dec 31, 2021 at 2:00 AM [email protected] wrote: > > I try to compute the factorial of a large number with tail-recursion > optimization decorator in Python3. The following code snippet is converted > from the code snippet given here [1] by the following steps: > > $ pyenv shell datasci > $ python --version > Python 3.9.1 > $ pip install 2to3 > $ 2to3 -w this-script.py > > ``` > # This program shows off a python decorator( > # which implements tail call optimization. It > # does this by throwing an exception if it is > # its own grandparent, and catching such > # exceptions to recall the stack. > > import sys > > class TailRecurseException: > def __init__(self, args, kwargs): > self.args = args > self.kwargs = kwargs > If it's an exception, it needs to subclass Exception or BaseException. (Also, is this REALLY an optimization? Exception handling isn't the fastest. Yes, it avoids some measure of recursion depth, but it looks like a pretty inefficient way to do things. Python is not Lisp, and there are very very few algorithms that actually benefit from tail call optimization that wouldn't benefit far more from other ways of doing the same thing.) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Fri, Dec 31, 2021 at 2:03 AM [email protected] wrote: > See here [1] for the related discussion. > > [1] > https://discuss.python.org/t/typeerror-catching-classes-that-do-not-inherit-from-baseexception-is-not-allowed/12800 Why did you post in two places at once? Did you need more people to tell you the same thing as the error message? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Thursday, December 30, 2021 at 11:23:35 PM UTC+8, Chris Angelico wrote: > If it's an exception, it needs to subclass Exception or BaseException. I see. That is, the following: class TailRecurseException(Exception): def __init__(self, args, kwargs): self.args = args self.kwargs = kwargs > (Also, is this REALLY an optimization? Exception handling isn't the > fastest. Yes, it avoids some measure of recursion depth, but it looks > like a pretty inefficient way to do things. Python is not Lisp, and > there are very very few algorithms that actually benefit from tail > call optimization that wouldn't benefit far more from other ways of > doing the same thing.) Could you give some examples of the other methods you mentioned above? > ChrisA HZ -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Thursday, December 30, 2021 at 11:24:20 PM UTC+8, Chris Angelico wrote: > On Fri, Dec 31, 2021 at 2:03 AM [email protected] > wrote: > > See here [1] for the related discussion. > > > > [1] > > https://discuss.python.org/t/typeerror-catching-classes-that-do-not-inherit-from-baseexception-is-not-allowed/12800 > Why did you post in two places at once? Did you need more people to > tell you the same thing as the error message? Doing so may attract the attention of developers, such as increasing the content of traceback information to make troubleshooting easier, just as André Roberge says here [1]. [1] https://discuss.python.org/t/typeerror-catching-classes-that-do-not-inherit-from-baseexception-is-not-allowed/12800/6?u=hongyi-zhao > ChrisA HZ -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Fri, Dec 31, 2021 at 9:42 AM [email protected] wrote: > > On Thursday, December 30, 2021 at 11:24:20 PM UTC+8, Chris Angelico wrote: > > On Fri, Dec 31, 2021 at 2:03 AM [email protected] > > wrote: > > > See here [1] for the related discussion. > > > > > > [1] > > > https://discuss.python.org/t/typeerror-catching-classes-that-do-not-inherit-from-baseexception-is-not-allowed/12800 > > Why did you post in two places at once? Did you need more people to > > tell you the same thing as the error message? > > Doing so may attract the attention of developers, such as increasing the > content of traceback information to make troubleshooting easier, just as > André Roberge says here [1]. > It's a simple question with a simple answer. You don't need to cross-post. All you do is split the discussion so people don't know what's already been said. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Fri, Dec 31, 2021 at 9:42 AM [email protected] wrote: > > (Also, is this REALLY an optimization? Exception handling isn't the > > fastest. Yes, it avoids some measure of recursion depth, but it looks > > like a pretty inefficient way to do things. Python is not Lisp, and > > there are very very few algorithms that actually benefit from tail > > call optimization that wouldn't benefit far more from other ways of > > doing the same thing.) > > Could you give some examples of the other methods you mentioned above? > If you have a function that has just a single tail call site, there's usually no point writing it recursively. def factorial(n): ret = 1 for i in range(1, n + 1): ret *= i return ret def fibonacci(n): a, b = 0, 1 for _ in range(n): a, b = b, a + b return a Neither of these wants to be recursive, and writing them recursively pollutes the function signature with parameters that really exist just to be local variables. Passing an accumulator down is a terrible way to demonstrate the beauty of recursion - it instead shows off how you can shoehorn anything into recursion and make it worse in the process. Please, everyone, stop trying to optimize the wrong things. Write good code, don't try to make bad code stop crashing. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
using OpenGL on windows 11
Hi! I am very new to Python admittedly, but did try several options regarding troubleshooting to get OpenGL to run with Python. I am using PyCharm as my interface, did try installing setup tools and have reinstalled using pip install function a few times. I did notice my machine seems to be having trouble remembering that I did install python and keeps prompting me to install from MS app store. I did try to do this but again did not register the installation of Python. I am able to open a window in PyCharm and get other functions to work but then get the Module not Installed error for OpenGL. I even tried the setuptools install and easy_install never popped up as an option. is this a windows 11 issue? does anything about this sound familiar? Thank you, and sorry if this has already been answered in a forum somewhere, I did look and could not find it -- Virginia Bliss [email protected] 678 640 1902 Los Angeles. CA -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Friday, December 31, 2021 at 7:04:24 AM UTC+8, Chris Angelico wrote: > Neither of these wants to be recursive, and writing them recursively > pollutes the function signature with parameters that really exist just > to be local variables. Passing an accumulator down is a terrible way > to demonstrate the beauty of recursion - it instead shows off how you > can shoehorn anything into recursion and make it worse in the process. Then what cases/scenarios can demonstrate the beauty of recursion? HZ -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On 2021-12-30 23:27, [email protected] wrote: On Friday, December 31, 2021 at 7:04:24 AM UTC+8, Chris Angelico wrote: Neither of these wants to be recursive, and writing them recursively pollutes the function signature with parameters that really exist just to be local variables. Passing an accumulator down is a terrible way to demonstrate the beauty of recursion - it instead shows off how you can shoehorn anything into recursion and make it worse in the process. Then what cases/scenarios can demonstrate the beauty of recursion? Walking a tree. -- https://mail.python.org/mailman/listinfo/python-list
Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
On Friday, December 31, 2021 at 7:50:48 AM UTC+8, MRAB wrote: > On 2021-12-30 23:27, [email protected] wrote: > > On Friday, December 31, 2021 at 7:04:24 AM UTC+8, Chris Angelico wrote: > >> Neither of these wants to be recursive, and writing them recursively > >> pollutes the function signature with parameters that really exist just > >> to be local variables. Passing an accumulator down is a terrible way > >> to demonstrate the beauty of recursion - it instead shows off how you > >> can shoehorn anything into recursion and make it worse in the process. > > > > Then what cases/scenarios can demonstrate the beauty of recursion? > > > Walking a tree. There are many type of trees. Do you mean all of them? -- https://mail.python.org/mailman/listinfo/python-list
RE: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed
Beauty of Recursion? Well, there is what I call Mathematical Beauty, and then there is reality. It is fantastic to prove neat theorems that something is possible by methods like mathematical induction that in some sense use recursion as in if something is true for some base value and it can be shown that if it is true for N then it also is true for N+1, then by a sort of recursion, it is true for every larger value! And, yes, you can write some seemingly neat and compact routines using recursion, but there are many run-time costs as Chris and others can suggest. Where is recursion most useful? I can think of many places but will briefly mention a few. There is a recursive sort algorithm that keeps dividing the data it is handled in two and calls itself recursively to process the first half and then again on the second half and simply merges the sorted results and returns that. Clearly this kind of algorithm calls itself to a depth of about log to the base two times. And a possible advantage here is that this can take some advantage of parallel architectures and some simultaneity. Another general set of recursive applications is anything that wanders tree-structures and looks for items or places new items in an appropriate place. If it is a binary tree, there is a slight similarity with my first example as there is a do_left and a do_right type of recursion but not really. And of course trees can have more than two branches and you can use recursion on other complex structures. But in some cases, you can come up with a non-recursive way to do things by keeping track of where you are and where you have been. Recursion is a good thing to teach but also a horrible thing when misused. A book I read decades ago, called The Little Lisper, showed algorithms such as asking for greater(A, B) to be done sort of like by recursively calling greater(subtract1(A), subtract1(B)) as long as neither A nor B becomes zero. Neat algorithm and tolerable for greater(3,5) returning 5 after a few recursions when 3 has been lowered to zero. Not so good with negative numbers. But greater(100, 101) might take a while and your machine may run out of memory and since you want to return the original value, tail recursion may not be enough unless you modify things a bit such as using a helper function that also includes the original numbers so it returns the right one or ... Many machines simply restrict you to compare numbers only up to the point where an int or float of some kind support it and then the operation of comparison is mostly just done in a few steps in the hardware no matter what size the two things are. Python with support for unlimited size integers though, ... -Original Message- From: Python-list On Behalf Of [email protected] Sent: Thursday, December 30, 2021 6:27 PM To: [email protected] Subject: Re: builtins.TypeError: catching classes that do not inherit from BaseException is not allowed On Friday, December 31, 2021 at 7:04:24 AM UTC+8, Chris Angelico wrote: > Neither of these wants to be recursive, and writing them recursively > pollutes the function signature with parameters that really exist just > to be local variables. Passing an accumulator down is a terrible way > to demonstrate the beauty of recursion - it instead shows off how you > can shoehorn anything into recursion and make it worse in the process. Then what cases/scenarios can demonstrate the beauty of recursion? HZ -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
