Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #46264 > unrolled thread

Re: Python error codes and messages location

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python error codes and messages location Fábio Santos <fabiosantosart@gmail.com> - 2013-05-28 09:10 +0100

#46264 — Re: Python error codes and messages location

[Multipart message — attachments visible in raw view] — view raw

On 28 May 2013 08:19, "Chris Angelico" <rosuav@gmail.com> wrote:
>
> On Tue, May 28, 2013 at 4:57 PM, Fábio Santos <fabiosantosart@gmail.com>
wrote:
> >
> > On 28 May 2013 05:17, "Vito De Tullio" <vito.detullio@gmail.com> wrote:
> >> I really hope really far... have you never tried to google a localized
> >> error
> >> message? :\
> >
> > Never. I don't even try.
>
> Same happens when someone pastes an error onto a mailing list like
> this. Unless there's some easily-identifiable token (maybe the
> exception type doesn't get localized, though that has its own
> consequences) by which everyone world-over can recognize the
> exception, this would be a major nuisance.

Just to clarify, I am suggesting to have the unchanged messages in
tracebacks, but having some methods in the exception to get the exception
and message localised. Just like repr() and str() are directed at different
audiences (the programmer vs. The user), so is a traceback vs a message box.

In English, we could "translate" the exception name (which is limited as a
python name). EG. RuntimeError -> Runtime error. Of course, this is not a
big deal, but it would let us show the error message to the user, together
with the exception.

It would be much harder to search for an error or ask for help if it was a
message written by some random developer.

OpenERP for example shows stack traces to the user. It could show a shorter
message in the user's language.

> Also, once the interpreter
> core and a few parts of the stdlib get localized, this would add a
> barrier to entry for new modules... not sure this is a good thing.

I think that would be a job for a per-language team as opposed to someone
implementing a bug fix or pushing a PEP? Even that would only be necessary
for the exceptions a module raises.

> Can we internationalize English instead of localizing Python?
>

That is worse than saying, "why don't we all just code in python?". Or c.
Or java. Or JavaScript.

Let's not get into that. I prefer len() to new
LengthCalculatorFactoryBuilder().createLengthCalculatorFactory().createLengthCalculator().calculateLengthOf().
And a good old Python list or JavaScript array to a collection of segfaults.

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web