Hi,
Python is optimized for performance. Formatting an error message has a
cost on performances.
I suggest you to teach your student to use the REPL and use a custom
exception handler: sys.excepthook:
https://docs.python.org/2/library/sys.html#sys.excepthook
Using a custom exception handler, you
On 29.11.2016 00:50, Brett Cannon wrote:
> Seventh, these *.missing.py files if they are directly executed are totally
> going to be abused like *.pth files, I can just feel it in my bones. We
> need to be okay with this if we accept this PEP as-is.
Since the purpose of the PEP was to allow distri
On 28 November 2016 at 22:33, Steve Dower wrote:
> Given that, this wouldn't necessarily need to be an executable file. The
> finder could locate a "foo.missing" file and raise ModuleNotFoundError with
> the contents of the file as the message. No need to allow/require any Python
> code at all, an
The existing docs for errors and exceptions:
- https://docs.python.org/2/library/exceptions.html
- https://docs.python.org/3/library/exceptions.html
- https://hg.python.org/cpython/file/tip/Doc/library/exceptions.rst
- https://github.com/python/cpython/blob/master/Doc/library/exceptions.rst
- htt
On Tue, Nov 29, 2016 at 1:05 AM, Victor Stinner
wrote:
> Hi,
>
> Python is optimized for performance. Formatting an error message has a
> cost on performances.
Sure, but we have to look at this on a case-by-case basis. Is there
really important code out there that's generating NameErrors or
Synta
> On 29 Nov 2016, at 02:48, Chris Angelico wrote:
>
> On Tue, Nov 29, 2016 at 12:14 PM, Steven D'Aprano wrote:
>> What if I have two files?
>>
>> # a.py
>> try:
>>import spam
>> except ImportError:
>>import ham as spam
>>
>> # b.py
>> try:
>>import spam
>> except ImportError:
>>
On 29.11.2016 10:39, Paul Moore wrote:
On 28 November 2016 at 22:33, Steve Dower wrote:
Given that, this wouldn't necessarily need to be an executable file. The
finder could locate a "foo.missing" file and raise ModuleNotFoundError with
the contents of the file as the message. No need to allow/
On 11/28/2016 05:38 PM, Guido van Rossum wrote:
Overall I think this is a good idea. I have one hit:
It seems that there are two possible strategies for searching the
.missing.py file:
1. (Currently in the PEP) search it at the same time as the .py file
when walking along sys.path.
- Pro:
On Tuesday, November 29, 2016, Nathaniel Smith wrote:
> On Tue, Nov 29, 2016 at 1:05 AM, Victor Stinner
> > wrote:
> > Hi,
> >
> > Python is optimized for performance. Formatting an error message has a
> > cost on performances.
>
> Sure, but we have to look at this on a case-by-case basis. Is the
On Tuesday, November 29, 2016, Wes Turner wrote:
> The existing docs for errors and exceptions:
>
> - https://docs.python.org/2/library/exceptions.html
> - https://docs.python.org/3/library/exceptions.html
> - https://hg.python.org/cpython/file/tip/Doc/library/exceptions.rst
> - https://github.co
On 29 November 2016 at 10:51, Wolfgang Maier
wrote:
> On 29.11.2016 10:39, Paul Moore wrote:
>>
>> On 28 November 2016 at 22:33, Steve Dower wrote:
>>>
>>> Given that, this wouldn't necessarily need to be an executable file. The
>>> finder could locate a "foo.missing" file and raise ModuleNotFoun
On 29 November 2016 at 08:01, Chris Barker wrote:
> On Mon, Nov 28, 2016 at 1:50 PM, Guido van Rossum wrote:
>>>
>>> Also -- the ship has kinda sailed on this - maybe a @not_override would
>>> make more sense.
>>>
>>> Isn't the goal to make sure you don't accidentally override a method?
>>> sayin
On 29 November 2016 at 20:38, Nathaniel Smith wrote:
> On Tue, Nov 29, 2016 at 1:05 AM, Victor Stinner
> wrote:
>> Hi,
>>
>> Python is optimized for performance. Formatting an error message has a
>> cost on performances.
>
> Sure, but we have to look at this on a case-by-case basis. Is there
> re
On 29 November 2016 at 03:28, Guido van Rossum wrote:
> On Mon, Nov 28, 2016 at 9:14 AM, Nathaniel Smith wrote:
>>
>> Also note that in Guido's option 2, we only incur the extra fstat calls if
>> the import would otherwise fail. In option 1, there are extra fstat calls
>> (and thus disk seeks etc
On 29 November 2016 at 20:54, Tomas Orsava wrote:
> With a metapath hook, .missing.py files are probably overkill, and the hook
> can just look at one file (or a static compiled-in list) of
> ModuleNotFound/ImportError messages for all missing modules, as M.-A.
> Lemburg and others are suggesting.
On Nov 29, 2016 5:51 AM, "Wolfgang Maier" <
[email protected]> wrote:
>
> On 29.11.2016 10:39, Paul Moore wrote:
>>
>> On 28 November 2016 at 22:33, Steve Dower wrote:
>>>
>>> Given that, this wouldn't necessarily need to be an executable file. The
>>> finder could locate a "
On Tue, Nov 29, 2016 at 4:13 AM, M.-A. Lemburg wrote:
> On 29.11.2016 00:50, Brett Cannon wrote:
> > Seventh, these *.missing.py files if they are directly executed are
> totally
> > going to be abused like *.pth files, I can just feel it in my bones. We
> > need to be okay with this if we accept
On 29/11/2016 04:58, victor rajewski wrote:
Traceback (most recent call last):
File "foo.py", line 2, in
l[10]=14
IndexError: list assignment index out of range
A better message might be:
You tried to use l[10] when l is only 4 elements long. You can add
items to l using l.append(v
On Tue, Nov 29, 2016 at 10:55:14AM -0500, Todd wrote:
> On Tue, Nov 29, 2016 at 4:13 AM, M.-A. Lemburg wrote:
> > Just as with .pth files, the possibility to hook arbitrary code
> > execution into the module search path will get abused for
> > all kinds of weird things, esp. if the whole sys.path
On Tue, 29 Nov 2016 at 02:39 Nathaniel Smith wrote:
> On Tue, Nov 29, 2016 at 1:05 AM, Victor Stinner
> wrote:
> > Hi,
> >
> > Python is optimized for performance. Formatting an error message has a
> > cost on performances.
>
> Sure, but we have to look at this on a case-by-case basis. Is there
On Tue, Nov 29, 2016 at 5:48 AM, Nick Coghlan wrote:
> > SyntaxErrors in an inner loop? That seems unlikely to me.
>
Syntax Errors are a special case, as by definition the code isn't being run
yet (yes, there could be an eval in there...)
So we could at least make those more informative without
I would consider the speed of the "ultimate error handler" (i.e. whatever
prints the traceback and kills the program) in the interpreter to be moot,
so long as it takes a small fraction of a second. Optimizing Python's speed
it crashes super-fast due to an *unhandled* NameError in your program seem
On Tue, 29 Nov 2016 at 06:49 Nick Coghlan wrote:
> On 29 November 2016 at 20:54, Tomas Orsava wrote:
> > With a metapath hook, .missing.py files are probably overkill, and the
> hook
> > can just look at one file (or a static compiled-in list) of
> > ModuleNotFound/ImportError messages for all m
On Tue, 29 Nov 2016 at 10:28 Nick Timkovich wrote:
> I would consider the speed of the "ultimate error handler" (i.e. whatever
> prints the traceback and kills the program) in the interpreter to be moot,
> so long as it takes a small fraction of a second. Optimizing Python's speed
> it crashes su
On 2016-11-29 09:43, Brett Cannon wrote:
One way to make this cheap is to have a reasonable default message and
use attributes on the exceptions trigger the use of the default message.
Nearly a year ago I filed a bunch of issues for ideas on providing
attributes on exceptions where it made sense,
On 11/29/2016 11:32 AM, Rob Cliffe wrote:
On 29/11/2016 04:58, victor rajewski wrote:
Traceback (most recent call last):
File "foo.py", line 2, in
l[10]=14
IndexError: list assignment index out of range
A better message might be:
You tried to use l[10] when l is only 4 elements lon
On Nov 29, 2016 9:43 AM, "Brett Cannon" wrote:
>
>
>
> On Tue, 29 Nov 2016 at 02:39 Nathaniel Smith wrote:
>>
>> On Tue, Nov 29, 2016 at 1:05 AM, Victor Stinner
>> wrote:
>> > Hi,
>> >
>> > Python is optimized for performance. Formatting an error message has a
>> > cost on performances.
>>
>> Su
On 2016-11-29 19:45, Brendan Barnwell wrote:
On 2016-11-29 09:43, Brett Cannon wrote:
One way to make this cheap is to have a reasonable default message and
use attributes on the exceptions trigger the use of the default message.
Nearly a year ago I filed a bunch of issues for ideas on providing
I actually thought about adding 'Exception.__hint__' attribute which
would have a longer message explaining what happened and how to fix it.
displayhooks can be easily modified to print __hint__ when it's set. We
can then add C API to set hints.
To address any possible performance concerns,
On 11/29/2016 1:33 PM, Brett Cannon wrote:
On Tue, 29 Nov 2016 at 06:49 Nick Coghlan mailto:[email protected]>> wrote:
On 29 November 2016 at 20:54, Tomas Orsava mailto:[email protected]>> wrote:
> With a metapath hook, .missing.py files are probably overkill, and
the hook
>
Mariatta Wijaya writes:
> > NameError: name 'length' is not defined
>
> > A better message might be:
>
> > Python doesn't recognise the function "length". Did you mean
> > len?'
This particular change would be useful to a beginning Python
programmer. I've made that error often enough mys
On 30 November 2016 at 04:33, Brett Cannon wrote:
> On Tue, 29 Nov 2016 at 06:49 Nick Coghlan wrote:
>>
>> On 29 November 2016 at 20:54, Tomas Orsava wrote:
>> > With a metapath hook, .missing.py files are probably overkill, and the
>> > hook
>> > can just look at one file (or a static compiled-
There are a couple of project that tried to improved heuristic on some
error messages.
Two I can think off are:
https://github.com/SylvainDe/DidYouMean-Python
and
https://github.com/dutc/didyoumean
I think that better error messages could be implemented only in the
repl, and/or by alternati
Victor Stinner writes:
> Using a custom exception handler, you can run expensive functions,
> like the feature: "suggest len when length is used".
LGTM.
> The problem is then when students have to use a Python without the
> custom exception handler.
Put the exception handler in an importabl
34 matches
Mail list logo
