Re: [Python-ideas] Better error messages [was: (no subject)]
On 11 December 2016 at 19:09, Sebastian Kreft wrote: > Note that there is a draft pep https://www.python.org/dev/peps/pep-0473/ > that aims at adding structured data to bultin exceptions. > > I've tried implementing some of those but had a couple of test failures that > weren't obvious to me how to solve. If you haven't already, note that it's OK to post proposed patches to the tracker even when they're still causing test failures - just note that you know the patch is incomplete, and explain the errors that you're seeing. Core developers will often be able to spot relevant problems through code review, and we're also pretty practiced at interpreting the sometimes cryptic failures that the test suite can emit. 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)]
Note that there is a draft pep https://www.python.org/dev/peps/pep-0473/ that aims at adding structured data to bultin exceptions. I've tried implementing some of those but had a couple of test failures that weren't obvious to me how to solve. On Dec 11, 2016 13:11, "Chris Barker" wrote: > On Sun, Dec 4, 2016 at 6:35 PM, Chris Angelico wrote: > >> I have no specific qualifications, but I teach online; > > > nor do I, and I teach for a continuing ed program -- not in high school. > > But anyway, regardless of official qualifications, good programmers are > not neccesray good teachers of programming. At all. > > 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. >> > > Exactly -- you can't be credentialed to teach Biology, or French, or > without knowing the subject. That may not yet be true for computer science, > as it is still "new" in high school curriculum, but it's still not Python's > job to overcome that. > > All the being said -- I don't think we should try to tailor error messages > specifically for newbies in the core interpreter, and the error messages > have gotten a lot better with py3, but they could still use some > improvement -- I would say that suggestions are welcome. > > And if they can be made (more) machine readable, so that an beginners IDE > would enhance them, that would be great. > > -CHB > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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)]
On Sun, Dec 4, 2016 at 6:35 PM, Chris Angelico wrote: > I have no specific qualifications, but I teach online; nor do I, and I teach for a continuing ed program -- not in high school. But anyway, regardless of official qualifications, good programmers are not neccesray good teachers of programming. At all. 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. > Exactly -- you can't be credentialed to teach Biology, or French, or without knowing the subject. That may not yet be true for computer science, as it is still "new" in high school curriculum, but it's still not Python's job to overcome that. All the being said -- I don't think we should try to tailor error messages specifically for newbies in the core interpreter, and the error messages have gotten a lot better with py3, but they could still use some improvement -- I would say that suggestions are welcome. And if they can be made (more) machine readable, so that an beginners IDE would enhance them, that would be great. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ 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)]
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)]
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)]
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)]
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 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. > 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. > 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. ___ 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 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)]
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)]
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)]
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)]
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)]
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)]
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 they prove > unuseful!) > > Steve > > >
[Python-ideas] Better error messages [was: (no subject)]
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/