On Thu, 31 Jan 2019 at 04:16, Stefan Behnel wrote:
> I faintly recall someone implementing something in that direction. It's
> probably in some package on PyPI.
You may be thinking of Doug Hellman's https://pypi.org/project/whatthewhat/
Cheers,
Nick.
P.S. More horrifyingly (in an amusing way),
Stefan Behnel wrote:
So … are you suggesting to use the webbrowser module inside of the REPL to
look up the exception message of the previously printed stack trace in
stack overflow when a user types "why()"?
"Python is searching for an answer to your question..."
--
Greg
On Wed, Jan 30, 2019 at 07:12:21PM +0100, Stefan Behnel
wrote:
> > I have a vague recollection that a certain computer system (Amiga?) had a
> > 'why' command. If it reported an error, you could type "why" and it would
> > give you more details.
> >
> > I suspect that all that was happening was
On 2019-01-30 18:12, Stefan Behnel wrote:
MRAB schrieb am 29.01.19 um 19:55:
On 2019-01-29 13:44, Nick Coghlan wrote:
FWIW, we have pretty decent evidence that error messages don't have to
provide a wonderful explanation on their own in order to be helpful:
they just need to be distinctive
MRAB schrieb am 29.01.19 um 19:55:
> On 2019-01-29 13:44, Nick Coghlan wrote:
>> FWIW, we have pretty decent evidence that error messages don't have to
>> provide a wonderful explanation on their own in order to be helpful:
>> they just need to be distinctive enough that a web search will
>>
Hello,
On Tue, 29 Jan 2019 18:55:37 +
MRAB wrote:
[]
> > https://stackoverflow.com/questions/25445439/what-does-syntaxerror-missing-parentheses-in-call-to-print-mean-in-python
> >
> I have a vague recollection that a certain computer system (Amiga?)
> had a 'why' command. If it reported
On 2019-01-29 13:44, Nick Coghlan wrote:
On Tue, 29 Jan 2019 at 14:47, Stephen J. Turnbull
wrote:
I don't disagree. I disagree with the conclusion that it's worth the
effort to try to improve all error messages that confuse new users,
because new users (by definition) don't know enough to
On Tue, 29 Jan 2019 at 14:47, Stephen J. Turnbull
wrote:
> I don't disagree. I disagree with the conclusion that it's worth the
> effort to try to improve all error messages that confuse new users,
> because new users (by definition) don't know enough to respond
> usefully in many cases. In
Chris Barker - NOAA Federal writes:
> > > But as a rule,
> > > there are a LOT of errors that can be pretty mysterious to newbies.
> >
> > Isn't that the very definition of "newbie"? That's half a joke, but I
> > really don't think that programmers new to Python should be the
> > standard.
> But as a rule,
>> there are a LOT of errors that can be pretty mysterious to newbies.
>
> Isn't that the very definition of "newbie"? That's half a joke, but I
> really don't think that programmers new to Python should be the
> standard.
Python is broadly advocated (and used) as a first
On Fri, 25 Jan 2019 at 10:15, Eric V. Smith wrote:
> It would be a change if the code is never called. I'm not sure we care
> about code that's never called, but it is a change.
The biggest problem with converting runtime errors to compile time
errors is that it means affected dead code goes
Chris Barker - NOAA Federal via Python-Dev writes:
> Well, yes, that particular example is pretty clear. But as a rule,
> there are a LOT of errors that can be pretty mysterious to newbies.
Isn't that the very definition of "newbie"? That's half a joke, but I
really don't think that
At the cost of breaking threading a bit, I'm going to reply to a few
different people in one post.
On Fri, Jan 25, 2019 at 09:52:53AM +1100, Chris Angelico wrote:
> On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote:
> > We could say that implementations are allowed to raise errors at
On 1/24/2019 6:16 PM, Eric V. Smith wrote:
On 1/24/2019 5:52 PM, Chris Angelico wrote:
+1. If it's something that the peephole optimizer is already allowed
to change (eg "1"+"1" is constant-folded) and there is absolutely no
way that it can ever be changed at run time, then raising at compile
On 1/24/2019 5:52 PM, Chris Angelico wrote:
On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote:
We could say that implementations are allowed to raise errors at compile
time instead of run time, but aren't required to. Then it becomes a
matter of "quality of implementation".
For literal
On Thu, Jan 24, 2019 at 3:45 PM Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> >. There's nothing mysterious about e.g. `TypeError: unsupported operand
> type(s) for +: 'int' and 'str'`, unlike the case of the two concatenated
> tuples. (Surely people get errors about int+str all
>. There's nothing mysterious about e.g. `TypeError: unsupported operand
type(s) for +: 'int' and 'str'`, unlike the case of the two concatenated
tuples. (Surely people get errors about int+str all the time, and they've
never complained -- unlike the tuple tuple case.)
Well, yes, that particular
On Thu, Jan 24, 2019 at 2:55 PM Chris Angelico wrote:
> On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano
> wrote:
> > We could say that implementations are allowed to raise errors at compile
> > time instead of run time, but aren't required to. Then it becomes a
> > matter of "quality of
On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano wrote:
> We could say that implementations are allowed to raise errors at compile
> time instead of run time, but aren't required to. Then it becomes a
> matter of "quality of implementation".
>
> For literal ints, strings, None, etc we can tell at
On Thu, Jan 24, 2019 at 04:01:26PM -0600, Neil Schemenauer wrote:
> On 2019-01-24, Terry Reedy wrote:
> > Serhiy Storchaka suggested a compiler SyntaxWarning and uploaded a
> > proof-of-concept diff that handled the above and many similar cases.
>
> I believe that in general we should give better
In this case I agree that a SyntaxWarning is a good idea, per Serhiy's
patch. I would be even more conservative, and only warn if the first object
is a tuple -- the case of the missing comma in the original example appears
likely enough, but I don't expect people to write e.g. `[[1, 2], (3, 4)]`
On 2019-01-24, Terry Reedy wrote:
> Serhiy Storchaka suggested a compiler SyntaxWarning and uploaded a
> proof-of-concept diff that handled the above and many similar cases.
I believe that in general we should give better errors or warnings
if we can do it without huge difficulty. Serhiy's patch
https://bugs.python.org/issue15248 is about situations like the following:
>>> [(1,2,3)
(4,5,6)]
Traceback (most recent call last):
File "", line 2, in
(4,5,6)]
TypeError: 'tuple' object is not callable
The original poster requested that the error message be augmented with
23 matches
Mail list logo
