Re: [Python-ideas] Better error messages [was: (no subject)]

[Nick Coghlan]

On 5 December 2016 at 12:35, Chris Angelico  wrote:
> On Mon, Dec 5, 2016 at 12:40 PM, Stephen J. Turnbull
>  wrote:
>> I don't know where you live, but in both of my countries there is a
>> teacher's union to ensure that nobody without an Ed degree gets near a
>> classroom.  More precisely, volunteers under the supervision of
>> somebody with professional teaching credentials, yes, day job, not in
>> this century.  And "teaching credentials" == degree from a state-
>> certified 4-year Ed program, not something you can get at a community
>> college in an adult ed program.
>
> Sadly, that's probably true here in Australia too, but I don't know
> for sure. I have no specific qualifications, but I teach online; it's
> high time the unions got broken IMO... but that's outside the scope of
> this. If it takes a credentialed teacher to get a job in a school, so
> be it - but at least make sure it's someone who knows how to interpret
> the error messages, so that any student who runs into trouble can ask
> the prof.

Graduate diplomas in Education in Australia are one- or two-year
certificate programs, and some state level industry-to-education
programs aim to get folks into the classroom early by offering
pre-approvals for teaching subjects specifically related to their area
of expertise.

However, the main problem isn't the credentials, and it's definitely
not unions, it's the fact that professional software developers have a
lot of options open to them both locally and globally, and "empower
the next generation to be the managers of digital systems rather than
their servants" has a lot of downsides compared to the alternatives
(most notably: you'll get paid a lot more in industry than you will as
a teacher, so opting for teaching as a change in career direction here
will necessarily be a lifestyle choice based on the non-monetary
factors. That's not going to change as long as people assume that
teaching is easy and/or not important).

That means that we're not at a point in history where we can assume
that teachers are going to be more computationally literate than their
students - instead, we need to assume that many of the teachers
involved will themselves be new to the concepts being taught and work
on empowering them *anyway*.

I just don't personally think that's feasible on a volunteer basis -
you need professional service providers that are familiar not only
with the specific concepts and technologies being taught, but also
with the bureaucratic context that the particular schools and teachers
they serve have to work within.

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[Nick Coghlan]

On 5 December 2016 at 09:15, victor rajewski  wrote:
> 
> There is currently a big push towards teaching coding and computational
> thinking to school students, but a lack of skilled teachers to actually be
> able to support this, and I don't see any initiatives that will address this
> in a long-term, large-scale fashion (I'm speaking primarily from an
> Australian perspective, and might be misreading the situation in other
> countries). It's worth considering a classroom where the teacher has minimal
> experience in programming, and a portion of the students have low confidence
> in computing matters. Anything that will empower either the teacher or the
> students to get past a block will be useful here; and error messages are, in
> my experience as a teacher, one of more threatening parts of Python for the
> beginner.
> 

Hi Victor,

I'm one of the co-coordinators of the PyCon Australia Education
Seminar, and agree entirely with what you say here. However, it isn't
a problem that *python-dev* is well-positioned to tackle. Rather, it
requires ongoing attention from vendors, volunteers and non-profit
organisations that are specifically focused on meeting the needs of
the educational sector. So your goal is valid, it's only your current
choice of audience that is slightly mistargeted.

Within Australia specifically, the two main drivers of the
improvements in Python's suitability for teachers are Grok Learning
(who provide a subscription-based online learning environment directly
to schools based on a service originally developed for the annual
National Computer Science School) and Code Club Australia (the
Australian arm of a UK-based non-profit aimed at providing support for
after-school code clubs around Australia, as well as professional
development opportunities for teachers needing to cope with the
incoming Digital Technologies curriculum).

> I'm not suggesting this should become part of the normal operation of
> Python, particularly if that breaks compatibility or impacts performance. A
> switch, or a seperate executable would probably work. I'd lean against the
> idea of tying this to a particular IDE/environment, but if that's the way
> this can progress, then let's do that to get it moving. However, it has to
> be dead simple to get it running.

The model adopted by Grok Learning and many other education focused
service providers (codesters.com, etc) is to provide the learning
environment entirely through the browser, as that copes with entirely
locked down client devices, and only requires whitelisting of the
vendor's site in the school's firewall settings. The only context
where it doesn't work is when the school doesn't have reliable
internet connectivity at all, in which case the cheap-dedicated-device
model driven by the UK's Raspberry Pi Foundation may be a more
suitable option.

> It will be almost impossible to deal with all cases, but that isn't the
> point here. The trick would be to find the most common errors that a
> beginning programmer will make, find the most common fixes, and provide them
> as hints, or suggestions.
> The examples listed in my original email are simply ideas, without much
> thought about how feasible (or useful) they are to implement. Going forward,
> we would identify common errors that beginners make, and what would help
> them fix these errors.

Right, and the folks best positioned to identify those errors
empirically, and also to make data-driven improvements based on the
typical number of iterations needed for beginners to fix their own
mistakes, are the educational service providers. Some of the more
sophisticated providers (like Knewton in the US) are even able to
adapt their curricula on the fly, offer learners additional problems
in areas they seem to be struggling with.

Don't get me wrong, there are definitely lots of areas where we can
make the default error messages more beginner friendly just by
providing relevant information that the interpreter has available, and
this is important for helping out the teachers that *don't* have
institutional mandates backing them up. But for cases like the
Australian Digital Curriculum, it makes sense for schools to look into
the local service providers rather than asking teachers to make do
with what they can download from the internet (while the latter option
is viable in some cases, it really does require a high level of
technical skill on the teacher's part)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[Chris Angelico]

On Mon, Dec 5, 2016 at 12:40 PM, Stephen J. Turnbull
 wrote:
> That's not exactly what he said.  High school teachers are likely to
> be the product of education schools, and may be highly skilled in
> building PowerPoint presentations, and have some experience in
> programming, but not as a professional.  So I can easily imagine a
> teacher responsible for several classes of 40 students for 2 hour-long
> sessions a week per class, and not being able to "interpret at a
> glance" many error messages produced by the Python interpreter.  This
> is basically the "aim for 90%" approach you describe, and he admits
> that's the best we can do.

Okay, then I misinterpreted. Seems we are indeed in agreement. Sounds good!

>  > IMO the right way to teach computer programming is for it to be the
>  > day job for people who do all their programming in open source and/or
>  > personal projects.  There are plenty of people competent enough to
>  > teach programming and would benefit from a day job.
>
> I don't know where you live, but in both of my countries there is a
> teacher's union to ensure that nobody without an Ed degree gets near a
> classroom.  More precisely, volunteers under the supervision of
> somebody with professional teaching credentials, yes, day job, not in
> this century.  And "teaching credentials" == degree from a state-
> certified 4-year Ed program, not something you can get at a community
> college in an adult ed program.

Sadly, that's probably true here in Australia too, but I don't know
for sure. I have no specific qualifications, but I teach online; it's
high time the unions got broken IMO... but that's outside the scope of
this. If it takes a credentialed teacher to get a job in a school, so
be it - but at least make sure it's someone who knows how to interpret
the error messages, so that any student who runs into trouble can ask
the prof.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[Stephen J. Turnbull]

Chris Angelico writes:
 > On Mon, Dec 5, 2016 at 10:15 AM, victor rajewski  wrote:

 > > There is currently a big push towards teaching coding and
 > > computational thinking to school students, but a lack of skilled
 > > teachers to actually be able to support this, and I don't see any
 > > initiatives that will address this in a long-term, large-scale
 > > fashion (I'm speaking primarily from an Australian perspective,
 > > and might be misreading the situation in other countries). It's
 > > worth considering a classroom where the teacher has minimal
 > > experience in programming, and a portion of the students have low
 > > confidence in computing matters. Anything that will empower
 > > either the teacher or the students to get past a block will be
 > > useful here; and error messages are, in my experience as a
 > > teacher, one of more threatening parts of Python for the
 > > beginner.
 > 
 > While I fully support enhancements to error messages (and the
 > possibility of a "programming student" mode that assumes a novice and
 > tweaks the messages accordingly), I don't think it's right to aim at a
 > classroom where *the teacher* doesn't have sufficient programming
 > skills.

That's not exactly what he said.  High school math teachers are likely
to be the product of education schools, and may be highly skilled in
building PowerPoint presentations, and have some experience in
programming, but not as a professional.  But nobody expects David
Beazley at Pigsty High!  So I can easily imagine a teacher responsible
for several classes of 40 students for 2 hour-long sessions a week per
class, who is unable to "interpret at a glance" many error messages
produced by the Python interpreter.  This is basically the "aim for
90%" approach you describe, and Victor admits that's the best we can
do.

And, realistically, in today's ed systems there *will* be teachers far
below the level you advocate.

 > IMO the right way to teach computer programming is for it to be the
 > day job for people who do all their programming in open source and/or
 > personal projects.  There are plenty of people competent enough to
 > teach programming and would benefit from a day job.

I don't know where you live, but in both of my countries there is a
teacher's union to ensure that nobody without an Ed degree gets near a
classroom.  More precisely, volunteers under the supervision of
somebody with professional teaching credentials, yes, day job, not in
this century.  And "teaching credentials" == degree from a state-
certified 4-year Ed program, not something you can get at a community
college in an adult ed program.  (Japan is somewhat more lenient than
that, but you do need a 4 year degree and a truckload of credits in ed
courses -- and it's not a career-track job.)

 > Design the error messages to minimize the load on the room's sole
 > expert, but assume that there'll always be someone around who can
 > deal with the edge cases. In other words, aim for the 90% or 95%,
 > rather than trying to explain 100% of situations.

I think we all agree on that being the best approach.



___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[Stephen J. Turnbull]

victor rajewski writes:

 >- I personally find the current error messages quite useful, and
 >they have the advantage of being machine-parseable, so that IDEs
 >such as PyCharm can add value to them. However, the audience of
 >this idea is not me, and probably not you. It is students who
 >are learning Python, and probably haven't done any programming
 >at all. But it might also be casual programmers who never really
 >look at error message as they are too computer-y.

That's a misconception.  You have not yet given up on a change to the
Python interpreter, so the audience is *every* user of the Python
interpreter (including other programs), and that's why you're getting
pushback.  The Python interpreter's main job is to execute code.  A
secondary job is provide *accurate* diagnostics of errors in
execution.  Interpreting those diagnostics is somebody else's job,
typically the programmer's.  For experienced programmers, that's
usually what you want, because (1) the interpretation is frequently
data-dependent and (2) the "obvious" suggestion may be wrong.

FYI, a *lot* of effort has gone into making error messages more
precise, more accurate, and more informative, eg, by improving stack
traces.

OTOH, if the diagnostics are accurate and machine-parsable, then the
amount of annoying detail that needs to be dealt with in providing a
"tutorial" front-end for those messages is small.  That suggests to me
that the problem really is that interpreting errors, even in "student"
programs, is *hard* and rules of thumb are frequently mistaken.
That's an excellent tradeoff if there's a teacher looking over the
(student) programmer's shoulder.  Not a good idea for the interpreter.

 >- I'm not suggesting this should become part of the normal
 >operation of Python, particularly if that breaks compatibility
 >or impacts performance. A switch, or a seperate executable would
 >probably work. I'd lean against the idea of tying this to a
 >particular IDE/environment, but if that's the way this can
 >progress, then let's do that to get it moving.

It really should be a separate executable.  There are multiple
implementations of Python, and even restricted to CPython, with even a
small amount of uptake this project will move a *lot* faster than
CPython does.  Every tiny change to the "better living through better
errors" database makes a difference to all the students out there, so
its release cycle should probably be really fast.

 >- The examples listed in my original email are simply ideas,
 >without much thought about how feasible (or useful) they are to
 >implement. Going forward, we would identify common errors that
 >beginners make, and what would help them fix these errors.

In other words, you envision a long-term project with an ongoing level
of effort.  I think that it's worth doing.  But I also think it's
quite feasible to put it in a separate project, with cooperation from
Python-Dev in the matter of ensuring that diagnostics are machine-
parseable.  Eg, this means that Python-Dev should not randomly change
messages that are necessary to interpret an Exception, and in some
cases it may be useful to add Exception/Error subtypes to make
interpretation more precise (though this will often get pushback).

___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[Chris Angelico]

On Mon, Dec 5, 2016 at 10:15 AM, victor rajewski  wrote:
> There is currently a big push towards teaching coding and computational
> thinking to school students, but a lack of skilled teachers to actually be
> able to support this, and I don't see any initiatives that will address this
> in a long-term, large-scale fashion (I'm speaking primarily from an
> Australian perspective, and might be misreading the situation in other
> countries). It's worth considering a classroom where the teacher has minimal
> experience in programming, and a portion of the students have low confidence
> in computing matters. Anything that will empower either the teacher or the
> students to get past a block will be useful here; and error messages are, in
> my experience as a teacher, one of more threatening parts of Python for the
> beginner.

While I fully support enhancements to error messages (and the
possibility of a "programming student" mode that assumes a novice and
tweaks the messages accordingly), I don't think it's right to aim at a
classroom where *the teacher* doesn't have sufficient programming
skills. Would you build a pocket calculator so it can be used in a
classroom where even the teacher doesn't know about division by zero?
Would you design a violin so a non-musician can teach its use?

IMO the right way to teach computer programming is for it to be the
day job for people who do all their programming in open source and/or
personal projects. There are plenty of people competent enough to
teach programming and would benefit from a day job. Design the error
messages to minimize the load on the room's sole expert, but assume
that there'll always be someone around who can deal with the edge
cases. In other words, aim for the 90% or 95%, rather than trying to
explain 100% of situations.

ChrisA
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[victor rajewski]

Thanks for all of the thoughtful replies (and for moving to a more useful
subject line).


There is currently a big push towards teaching coding and computational
thinking to school students, but a lack of skilled teachers to actually be
able to support this, and I don't see any initiatives that will address
this in a long-term, large-scale fashion (I'm speaking primarily from an
Australian perspective, and might be misreading the situation in other
countries). It's worth considering a classroom where the teacher has
minimal experience in programming, and a portion of the students have low
confidence in computing matters. Anything that will empower either the
teacher or the students to get past a block will be useful here; and error
messages are, in my experience as a teacher, one of more threatening parts
of Python for the beginner.


A few clarifications and thoughts arising from the discussion:

   - I personally find the current error messages quite useful, and they
   have the advantage of being machine-parseable, so that IDEs such as PyCharm
   can add value to them. However, the audience of this idea is not me, and
   probably not you. It is students who are learning Python, and probably
   haven't done any programming at all. But it might also be casual
   programmers who never really look at error message as they are too
   computer-y.
   - Learning how to parse an error message is a very valuable skill for a
   programmer to learn. However, I believe that should come later on in their
   journey. A technical error message when a student is starting out can be a
   bit overwhelming to some learners, who are already taking in a lot of
   information.
   - I'm not suggesting this should become part of the normal operation of
   Python, particularly if that breaks compatibility or impacts performance. A
   switch, or a seperate executable would probably work. I'd lean against the
   idea of tying this to a particular IDE/environment, but if that's the way
   this can progress, then let's do that to get it moving. However, it has to
   be dead simple to get it running.
   - I think this is necessary for scripts as well as the REPL (also other
   envs like Jupyter notebooks).
   - It will be almost impossible to deal with all cases, but that isn't
   the point here. The trick would be to find the most common errors that a
   beginning programmer will make, find the most common fixes, and provide
   them as hints, or suggestions.
   - The examples listed in my original email are simply ideas, without
   much thought about how feasible (or useful) they are to implement. Going
   forward, we would identify common errors that beginners make, and what
   would help them fix these errors.

-- 

Victor Rajewski
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[Nick Coghlan]

On 30 November 2016 at 19:05, Paul Moore  wrote:
> On 30 November 2016 at 02:14, Stephen J. Turnbull
>  wrote:
>> Wouldn't
>>
>> NameError: Python doesn't recognize the name "log".  Perhaps
>> you need to import the "math" module?
>
> ... and of course up until this example, I'd assumed you were talking
> about the log function from the logging module :-)
>
> I'm a strong +1 on better error messages, but there's always a risk
> with heuristics that the resulting messages end up worse, not better.
>
> Maybe keep it simpler:
>
> NameError: Python doesn't recognize the name "log". Maybe you
> misspelled the name, or did you mean to import the function from a
> module?
>
> and don't try to guess the user's intent.

This brings up a point that I was going to mention earlier: when it
comes to specialised learning environments, the folks developing the
curriculum also know *what problem the student is working on*, and can
tailor their error messages accordingly.

The reference interpreter is never going to be able to guess intent
like that due to the sheer scope of Python's use cases - by covering
everything from students writing "Guess a number" games to mechanical
engineers modeling and tuning race car performance to sysadmins
automating service deployments to web developers responding to user
requests to data analysts trying to make sense of noisy data, we end
up being *really* limited in the assumptions we can make about what a
user was really trying to do when they accidentally ask for something
nonsensical.

Tweaking some of the default representations to mention common
problems should be OK, though. While some veteran programmers may find
such prompts a bit condescending, they'd be better equipped than
beginners to opt in to alternative exception display options that omit
the hints.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[Paul Moore]

On 30 November 2016 at 02:14, Stephen J. Turnbull
 wrote:
> How about:
>
> class Blog:
> pass
>
> blog = get_blog_for_date(someday)
>
> logn = log(blog.size)
>
> NameError: Python doesn't recognize the function "log".  Did you
> mean "Blog"?
>
> Wouldn't
>
> NameError: Python doesn't recognize the name "log".  Perhaps
> you need to import the "math" module?

... and of course up until this example, I'd assumed you were talking
about the log function from the logging module :-)

I'm a strong +1 on better error messages, but there's always a risk
with heuristics that the resulting messages end up worse, not better.

Maybe keep it simpler:

NameError: Python doesn't recognize the name "log". Maybe you
misspelled the name, or did you mean to import the function from a
module?

and don't try to guess the user's intent.

Paul
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Better error messages [was: (no subject)]

[Matthias Bussonnier]

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 alternative repl. Having it as an opt-in library would
be useful to tweak the messages in various context, for example when
used for teaching, or if there are concern about overhead.

Some alternative even already implement heuristic (Recursions error in
IPython are elided with "... last  frames repeated, from the frame
below ..." which is way less scarier for beginners. Some other
attempts have been made with attributes error[1] (similar to what
Stephen is proposing), though the traceback info does not have a ref
(or even weakref) on the object on which the attributes access is
made, so even more heuristic have to be made.

Maybe just adding some more information on exception themselves and
giving the recipe of custom except hook would be enough.
Then just allow users to pip-install packages with heuristics ?


-- 
M
[1] https://github.com/ipython/ipython/pull/9073

On Tue, Nov 29, 2016 at 6:14 PM, Stephen J. Turnbull
 wrote:
> 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 myself (maybe I'm not a
> good example, though, in Lisp the generic function with the same role
> *is* called "length", so I make that error even today).
>
> But I wonder if it's a good example for the generic case.  An error
> message of the form 'Python doesn't recognize the function "".
> Did you mean ""?' could easily be misleading.  Python has
> functions, but they're a type of object.  "length" is a name, which is
> not an object.  The expected type of the object is not function, it's
> callable.  So consider:
>
> class Blog:
> pass
>
> blog = log()
>
> NameError: Python doesn't recognize the function "log".  Did you
> mean "Blog"?
>
> I suspect that might cause cognitive dissonance in a beginner who
> thinks of a class as a type or data structure and not as a function.
> And "doesn't recognize the callable" might be awkward (or beginners
> might get used to it very quickly, I don't know).
>
> Also, how do you propose deciding on the alternative to suggest?  In
> this particular case, I expect most developers would agree
> intuitively.  But the Hamming distance is pretty large: 3 of a length
> of 6.  Would you have a dictionary of common errors, and then scan the
> namespace for minimum Hamming distance among defined names with the
> right type of value?
>
> How about:
>
> class Blog:
> pass
>
> blog = get_blog_for_date(someday)
>
> logn = log(blog.size)
>
> NameError: Python doesn't recognize the function "log".  Did you
> mean "Blog"?
>
> Wouldn't
>
> NameError: Python doesn't recognize the name "log".  Perhaps
> you need to import the "math" module?
>
> be a better message here?  On second thought, that might imply that
> calling with the unqualified name is generally the best style, and
> teach the beginner to insert
>
> from math import *
>
> at the top of the module, thus fixing all such errors.  We probably
> don't want that, so maybe
>
> NameError: Python doesn't recognize the name "log".  There are
> functions named "log" in the "math" module and the "cmath" module.
>
> would be better yet.
>
> I definitely agree that there are times when Python's error messages
> are quite impenetrable for the beginner, and improvement is
> desirable.  I think that I would probably attack this by looking at
> the builtin namespace and a few stdlib namespaces (math, string, and
> maybe cmath come immediately to mind), and create a dictionary of
> "intuitive beginner errors".  Then trap NameErrors, and preferentially
> emit the message from the dictionary on exact matches.  Actually, come
> to think of it, two dictionaries, one for the builtin namespace, one
> for the selected stdlib, and the following heuristic:
>
> if name in common_builtin_typos:
> emit(common_builtin_typos[name])
> else:
> errors = small_hamming_distance(name, current_namespace, syntax(name))
> if errors:
> emit(errors)
> else:
> errors = exact_matches_in_imported_modules(name)
> if errors:
> emit(errors)
> elif name in common_unimported_stdlib_names:
> emit(common_unimported_stdlib_names[name])
> else:
> emit(error_you_would_have_emitted_anyway)
>
> In other words, I don't see a good systematic way to go about this,
> just pile up heuristics (and maybe remove some as 

[Python-ideas] Better error messages [was: (no subject)]

[Stephen J. Turnbull]

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 myself (maybe I'm not a
good example, though, in Lisp the generic function with the same role
*is* called "length", so I make that error even today).

But I wonder if it's a good example for the generic case.  An error
message of the form 'Python doesn't recognize the function "".
Did you mean ""?' could easily be misleading.  Python has
functions, but they're a type of object.  "length" is a name, which is
not an object.  The expected type of the object is not function, it's
callable.  So consider:

class Blog:
pass

blog = log()

NameError: Python doesn't recognize the function "log".  Did you
mean "Blog"?

I suspect that might cause cognitive dissonance in a beginner who
thinks of a class as a type or data structure and not as a function.
And "doesn't recognize the callable" might be awkward (or beginners
might get used to it very quickly, I don't know).

Also, how do you propose deciding on the alternative to suggest?  In
this particular case, I expect most developers would agree
intuitively.  But the Hamming distance is pretty large: 3 of a length
of 6.  Would you have a dictionary of common errors, and then scan the
namespace for minimum Hamming distance among defined names with the
right type of value?

How about:

class Blog:
pass

blog = get_blog_for_date(someday)

logn = log(blog.size)

NameError: Python doesn't recognize the function "log".  Did you
mean "Blog"?

Wouldn't

NameError: Python doesn't recognize the name "log".  Perhaps
you need to import the "math" module?

be a better message here?  On second thought, that might imply that
calling with the unqualified name is generally the best style, and
teach the beginner to insert

from math import *

at the top of the module, thus fixing all such errors.  We probably
don't want that, so maybe

NameError: Python doesn't recognize the name "log".  There are
functions named "log" in the "math" module and the "cmath" module.

would be better yet.

I definitely agree that there are times when Python's error messages
are quite impenetrable for the beginner, and improvement is
desirable.  I think that I would probably attack this by looking at
the builtin namespace and a few stdlib namespaces (math, string, and
maybe cmath come immediately to mind), and create a dictionary of
"intuitive beginner errors".  Then trap NameErrors, and preferentially
emit the message from the dictionary on exact matches.  Actually, come
to think of it, two dictionaries, one for the builtin namespace, one
for the selected stdlib, and the following heuristic:

if name in common_builtin_typos:
emit(common_builtin_typos[name])
else:
errors = small_hamming_distance(name, current_namespace, syntax(name))
if errors:
emit(errors)
else:
errors = exact_matches_in_imported_modules(name)
if errors:
emit(errors)
elif name in common_unimported_stdlib_names:
emit(common_unimported_stdlib_names[name])
else:
emit(error_you_would_have_emitted_anyway)

In other words, I don't see a good systematic way to go about this,
just pile up heuristics (and maybe remove some as they prove
unuseful!)

Steve


___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/