On 24 February 2015 at 18:40, M.-A. Lemburg <mal at egenix.com> wrote:
> On 23.02.2015 23:50, Nick Coghlan wrote:
>> On 24 February 2015 at 08:40, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> On 24 February 2015 at 07:39, Mark Lawrence <breamoreboy at yahoo.co.uk> wrote:
>>>> On 23/02/2015 21:27, Serhiy Storchaka wrote:
>>>>>
>>>>> On 23.02.15 21:58, Joao S. O. Bueno wrote:
>>>>>>
>>>>>> That happens all the time, and is this use case that should possibly
>>>>>> be addressed here - maybe
>>>>>> something as simple as adding a couple of paragraphs to different places
>>>>>> in the documentation could mitigate the issue. (in contrast to make a
>>>>>> tons of otherwise valid code
>>>>>> to become deprecated in a couple releases).
>>>>>
>>>>>
>>>>> The problem is that the user don't know that he should read the
>>>>> documentation. It just find that his script works with "C:\sample.txt",
>>>>> but doesn't work with "D:\test.txt". He has no ideas what happen.
>>>>
>>>> Isn't this why users have help desks?
>>>
>>> Most don't, and cases like "\n" or "\t" in a Windows path name being
>>> converted to whitespace are utterly impossible to look up in an
>>> internet search when they fail, so a user learning on their own gets
>>> left with a broken program and no particularly effective ways to ask
>>> for help figuring it out.
>
> I think the easiest way would be to tweak the error message
> output to indicate the real problem.
>
> At the moment, you get:
>
>>>> open('c:\test.txt')
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> FileNotFoundError: [Errno 2] No such file or directory: 'c:\test.txt'
>
> which isn't helpful.
>
> It would be better to display the escapes as what they are:
>
> FileNotFoundError: [Errno 2] No such file or directory: 'c: est.txt'
>
> or use a special representation function to highlight the
> possible problem:
>
> FileNotFoundError: [Errno 2] No such file or directory: 'c:[\t]est.txt' - warning: embedded escapes
>
> with the representation being:
>
> "'c:[\t]est.txt' - warning: embedded escapes"
>
> Such a change doesn't require a deprecation phase or a PEP.
Oh, I like that idea, especially the variant that includes a search
friendly phrase like "embedded escapes" in the error message. And
unlike changing the handling of string literals generally, the impact
would be isolated to a few exception __repr__ implementations.
Regards,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4