Re: how to discover what values produced an exception?
Johanne Fairchild wrote at 2024-5-3 10:56 -0300: >How to discover what values produced an exception? Or perhaps---why >doesn't the Python traceback show the values involved in the TypeError? >For instance: > >--8<>8--- (0,0) < 4 >Traceback (most recent call last): > File "", line 1, in >TypeError: '<' not supported between instances of 'tuple' and 'int' >--8<>8--- > >It could have said something like: > >--8<>8--- >TypeError: '<' not supported between instances of 'tuple' and 'int' > in (0,0) < 4. >--8<>8--- > >We would know which were the values that caused the problem, which would >be very helpful. Typically, the traceback informs you about the source code line where the exception has been raised. When the source line contains literals, you see the values. If not, then only in special (speak: rather simple) cases the knowledge of the values will help much. Usually, a more thorough analysis is required to find out the bug location and how to fix the bug. -- https://mail.python.org/mailman/listinfo/python-list
Re: how to discover what values produced an exception?
On 2024-05-03 at 10:56:39 -0300, Johanne Fairchild via Python-list wrote: > How to discover what values produced an exception? Or perhaps---why > doesn't the Python traceback show the values involved in the TypeError? > For instance: > > --8<>8--- > >>> (0,0) < 4 > Traceback (most recent call last): > File "", line 1, in > TypeError: '<' not supported between instances of 'tuple' and 'int' > --8<>8--- > > It could have said something like: > > --8<>8--- > TypeError: '<' not supported between instances of 'tuple' and 'int' > in (0,0) < 4. > --8<>8--- > > We would know which were the values that caused the problem, which would > be very helpful. I'm not disagreeing that knowing the values could be useful in many cases. In the general case, though, it's not practical. Consider a function like this: def f(x, y): return g(x) < h(y) The printed values of x, y, g(x), and h(y) could all be millions of (or more) glyphs. Worse, one or more of those values could contain circular lists or similar structures. And h or g could have changed x or y. In summary, printing run-time values isn't always safe or useful. At least printing the types is safe. In the face of ambiguity, refuse to guess. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Dialogs
On 2024-05-02 16:34:38 +0200, Loris Bennett via Python-list wrote: > [email protected] (Stefan Ram) writes: > > Me (indented by 2) and the chatbot (flush left). Lines lengths > 72! > > Is there a name for this kind of indentation, i.e. the stuff you are > writing not being flush left? Ramism. > It is sort of contrary to what I think of as "normal" indentation. Stefan is well known for doing everything contrary to normal convention. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | [email protected] |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Issues with uninstalling python versions on windows server
On 5/3/24 05:55, Tripura Seersha via Python-list wrote: Hi Team, I am working on an automation related to uninstalling and installing python versions on different windows servers. I have observed that uninstallation is working only with the account/login using which the python version is installed. But for automation, we are not aware which account is being used for installation on different machines. If you want to automate things properly, you need to control installation as well as uninstallation - if things are just installed via some random user account it's hard to see how you can expect later steps without that knowledge to work out. There's a fair bit of control available; if you haven't already, take a look here: https://docs.python.org/3/using/windows.html#installing-without-ui -- https://mail.python.org/mailman/listinfo/python-list
