Re: Python Dialogs
On Tue, 7 May 2024 at 03:42, jak via Python-list wrote: > > Loris Bennett ha scritto: > > r...@zedat.fu-berlin.de (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? It is sort of contrary to > > what I think of as "normal" indentation. You seem to use it in all your > > postings, too, which hurts my brain, but I guess that's my problem :-) > > > > [snip (40 lines)] > > > > It's not just your problem. When the texts are particularly long and > complex, I happen to use Google-Translator. It makes bad translations if > the lines are interrupted by the newline, so I wrote a tool dedicated to > Stefan and to all those who indent like him. This tool takes the text > from the clipboard, removes all the superfluous spaces, combines all the > lines in one and puts the result back into the clipboard. :-D > Fun fact: His posts are completely irrelevant to people who follow the mailing list. Due to a dispute over permissions, his posts are blocked at the gateway. So all of us folks who use the mailing list never need to see the wonky indentation. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: how to discover what values produced an exception?
On Tue, 7 May 2024 at 03:38, Alan Bawden via Python-list wrote: > A good error message shouldn't withhold any information that can > _easily_ be included. Debugging is more art than science, so there is > no real way to predict what information might prove useful in solving > the crime. I emphasized "easily" because of course you have to draw the > line somewhere. Emphasis on "easily" is correct here. How easy is it to report the value of something that could be arbitrarily large? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Dialogs
Loris Bennett ha scritto: r...@zedat.fu-berlin.de (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? It is sort of contrary to what I think of as "normal" indentation. You seem to use it in all your postings, too, which hurts my brain, but I guess that's my problem :-) [snip (40 lines)] It's not just your problem. When the texts are particularly long and complex, I happen to use Google-Translator. It makes bad translations if the lines are interrupted by the newline, so I wrote a tool dedicated to Stefan and to all those who indent like him. This tool takes the text from the clipboard, removes all the superfluous spaces, combines all the lines in one and puts the result back into the clipboard. :-D -- https://mail.python.org/mailman/listinfo/python-list
Re: Python Dialogs
Stefan Ram ha scritto:
r...@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
translation services are gonna interpret line breaks as
I just beefed up my posting program to replace "gonna".
Now I won't come across like some street thug, but rather
as a respectable member of human society!
# replace complete words
replacements =\
{ rb'kind of': b'kind of',
rb'trying to': b'trying to',
rb'got to': b'got to',
rb'gonna': b'going to',
}
lines =\
[ re.sub( rb"\b(" + b"|".join( replacements.keys() ) + rb")\b",
lambda x: replacements[ x.group() ], line )
if len( line )and line[ 0 ]not in b'>|' else line for line in lines ]
I present to you the brutality to which your posts are subjected:
for(d = s = pCLipb; *s != TEXT('\0'); s++)
{
if(d == pCLipb)
{
if(*s != TEXT(' ') && *s != TEXT('\n') && *s != TEXT('\r'))
*d++ = *s;
}
else if(*s == TEXT(' ') || *s == TEXT('\n') || *s == TEXT('\r'))
{
if(d[-1] != TEXT(' '))
*d++ = TEXT(' ');
}
else
*d++ = *s;
}
*d = TEXT('\0');
--
https://mail.python.org/mailman/listinfo/python-list
Re: how to discover what values produced an exception?
From a practical perspective: not all values are printable (especially if printing a value results in an error: then you'd lose the original error, so, going crazy with printing of errors is usually not such a hot idea). But, if you want the values: you'd have to examine the stack, extract the values from the local variables etc. It's easier to do this interactively (unless you are in a multithreaded environment, where pdb is broken). But, you could also try to find this information automatically (by unwinding the stack to the place that generated the error, examining the local variables etc.) It's tedious and prone to errors. So, if you really want to do this automatically for every error that's going to be quite a bit of work. On Fri, May 3, 2024 at 6:58 PM 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. > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: how to discover what values produced an exception?
Thomas Passin writes:
On 5/3/2024 9:56 AM, 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.
In this example it would not help at all to know the actual values. Knowing
that you are trying to compare incomparable types is enough.
In general, it absolutely can help. The programmer can sometimes
recognize where a value of unexpected type came from just by looking at
it, allowing her to quickly deduce just what went wrong without further
investigation.
A good error message shouldn't withhold any information that can
_easily_ be included. Debugging is more art than science, so there is
no real way to predict what information might prove useful in solving
the crime. I emphasized "easily" because of course you have to draw the
line somewhere.
The fact that Python error messages often fail to mention the actual
objects that caused the error has always annoyed me. I've always
presumed that for some reason it just wasn't easy to do. And it's never
been more than a minor annoyance to me.
So the OP is not wrong for wishing for this. Other programming
languages do it. Other Python programmers miss it.
- Alan
--
https://mail.python.org/mailman/listinfo/python-list
