We have been supplying many possible reasons or consequences for why the implementation of python does not do what the OP wants and even DEMANDS.
I am satisfied with knowing it was because they CHOSE NOT TO in some places and maybe not in others. It is nice to see some possible reasons, but something as simple as efficiency or needing to complicate the code in something used regularly, might be enough for now. But to comment on what Michael T. and Dave N. have been saying, newcomers often have no clue of what can happen so their questions may sound quite reasonable. So what happens if you create a large data structure, so some operation that fails, catch the error and save the variables involved in an exception and throw that onward and perhaps the program keeps running? There is now a pointer to the large data structure in the exception object, or even a copy. If that exception is not discarded or garbage collected, it can remain in memory indefinitely even if the original string was expected to be removed, replaced, or garbage collected. Some modern features in R such as generators will stay alive infinitely and retain their state in between calls for a next item. You can end up with memory leaks that are not trivial to solve or that may mysteriously disappear when an iterable has finally been consumed and all the storage it used or pointed at can be retrieved, as one example. A more rational approach is to realize that python has multiple levels of debugging and exceptions are one among many. They are not meant to solve the entire problem but just enough to be helpful or point you in some direction. Yes, they can do more. And, FYI, I too pointed this person at the Tutor list and I see no sign they care how many people they make waste their time with so many mainly gripes. I personally now ignore any post by them. -----Original Message----- From: Python-list <python-list-bounces+avi.e.gross=gmail....@python.org> On Behalf Of Michael Torrie Sent: Thursday, February 23, 2023 10:32 PM To: python-list@python.org Subject: Re: Why doesn't Python (error msg) tell me WHAT the actual (arg) values are ? On 2/23/23 01:08, Hen Hanna wrote: > Python VM is seeing an "int" object (123) (and telling me that) ... so it should be easy to print that "int" object > What does Python VM know ? and when does it know it ? It knows there is an object and its name and type. It knows this from the first moment you create the object and bind a name to it. > it seems like it is being playful, teasing (or mean), and hiding the ball from me Sorry you aren't understanding. Whenever you print() out an object, python calls the object's __repr__() method to generate the string to display. For built-in objects this is obviously trivial. But if you were dealing an object of some arbitrary class, there may not be a __repr__() method which would cause an exception, or if the __repr__() method itself raised an exception, you'd lose the original error message and the stack trace would be all messed up and of no value to you. Does that make sense? Remember that Python is a very dynamic language and what might be common sense for a built-in type makes no sense at all for a custom type. Thus there's no consistent way for Python to print out the information you think is so simple. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
