Folks,
It seems changing anything about how Exception messages are handles is off
the table for 2.7, and a non-issue in 3.*
Is it worth opening an issue on this, just so we can close it as won't fix?
Or is this thread documentation enough?
NOTE about py3: I'm assuming unicode messages are
On Mon, Nov 18, 2013 at 12:15 PM, Chris Barker chris.bar...@noaa.govwrote:
Folks,
It seems changing anything about how Exception messages are handles is off
the table for 2.7, and a non-issue in 3.*
Is it worth opening an issue on this, just so we can close it as won't
fix? Or is this
Hi,
FWIW, the pure Python traceback.py module has a slightly different
(and saner) behavior:
e = Exception(uxx\u1234yy)
traceback.print_exception(Exception, e, None)
Exception: xx\u1234yy
I'd suggest that the behavior of the two should be unified anyway.
The traceback module uses
Am 15.11.13 00:57, schrieb Chris Barker:
Maybe so -- but we are either maintaining 2.7 or not -- it WIL be
around for along time yet...
Procedurally, it's really easy. Ultimately it's up to the release
manager to decide which changes go into a release and which don't, and
Benjamin has already
Hi again,
I figured that even using the traceback.py module and getting
Exception: \u1234\u1235\u5321 is rather useless if you tried to
raise an exception with a message in Thai. I believe this to also be
a bug, so I opened https://bugs.pypy.org/issue1634 . According to
this thread, however,
On Fri, Nov 15, 2013 at 9:21 AM, Armin Rigo ar...@tunes.org wrote:
I figured that even using the traceback.py module and getting
Exception: \u1234\u1235\u5321 is rather useless if you tried to
raise an exception with a message in Thai.
yup.
I believe this to also be
a bug, so I opened
On Fri, Nov 15, 2013 at 12:41 PM, Chris Barker chris.bar...@noaa.govwrote:
On Fri, Nov 15, 2013 at 9:21 AM, Armin Rigo ar...@tunes.org wrote:
I figured that even using the traceback.py module and getting
Exception: \u1234\u1235\u5321 is rather useless if you tried to
raise an exception
On Fri, Nov 15, 2013 at 5:24 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Procedurally, it's really easy. Ultimately it's up to the release
manager to decide which changes go into a release and which don't, and
Benjamin has already voiced an opinion.
Very early in the conversation, though
Armin Rigo wrote:
I figured that even using the traceback.py module and getting
Exception: \u1234\u1235\u5321 is rather useless if you tried to
raise an exception with a message in Thai.
But at least it tells you that *something* went wrong,
and points to the place in the code where it
Folks,
(note this is about 2.7 -- sorry, but a lot of us still use that! I
can only assume that in 3.* this is a non-issue)
I just discovered an issue that's been around a long time:
If you create an Exception with a unicode object for the message, the
message can be silently ignored if it can
2013/11/14 Chris Barker chris.bar...@noaa.gov:
So a proposal:
Use 'replace mode for the encoding to the default, and at least the
user would see SOMETHING of the message. In a common case, it would be
a lot of ascii, and in the worse case it would be a lot of question
marks -- still better
2013/11/14 Chris Barker chris.bar...@noaa.gov:
(note this is about 2.7 -- sorry, but a lot of us still use that! I
can only assume that in 3.* this is a non-issue)
I just discovered an issue that's been around a long time:
If you create an Exception with a unicode object for the message,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/14/2013 04:02 PM, Benjamin Peterson wrote:
2013/11/14 Chris Barker chris.bar...@noaa.gov:
So a proposal:
Use 'replace mode for the encoding to the default, and at least
the user would see SOMETHING of the message. In a common case, it
On 11/14/2013 4:55 PM, Tres Seaver wrote:
About the only things I can think of which might break would be doctests,
but people *expect* those to break across third-dot releases of Python
(one reason why I hate them).
My impression is that we avoid enhancing correct exception messages in
On 11/14/2013 02:59 PM, Terry Reedy wrote:
On 11/14/2013 4:55 PM, Tres Seaver wrote:
About the only things I can think of which might break would be doctests,
but people *expect* those to break across third-dot releases of Python
(one reason why I hate them).
My impression is that we avoid
On Thu, Nov 14, 2013 at 04:55:19PM -0500, Tres Seaver wrote:
Fixing any bug is changing behavior; 2.7 is not frozen for bugfixes.
It's not a given that the current behaviour *is* a bug. Exception
messages in 2 are byte-strings, not Unicode. Trying to use Unicode
instead is not, as far as I
On Thu, Nov 14, 2013 at 1:55 PM, Tres Seaver tsea...@palladion.com wrote:
Fixing any bug is changing behavior; 2.7 is not frozen for bugfixes.
Thank you.
The real question is whether third-party code will break when the
now-empty error messages appear with '?' littered through them?
right
On Thu, Nov 14, 2013 at 1:20 PM, Victor Stinner
If you create an Exception with a unicode object for the message, (...)
In Python 2, there are too many similar corner cases. It is impossible
to fix these bugs without taking the risk of introducing a regression.
Yes, there are -- the
On Thu, Nov 14, 2013 at 3:58 PM, Steven D'Aprano st...@pearwood.info wrote:
It's not a given that the current behaviour *is* a bug.
I'll concede that it's not a bug unless someone said somewhere that
unicode messages should work .. but that's kind of a semantic
argument.
I have to say it's a
On 11/14/2013 6:57 PM, Chris Barker wrote:
On Thu, Nov 14, 2013 at 1:20 PM, Victor Stinner
Seriously, *all* these tricky bugs are fixed in Python 3. So don't
loose time on trying to workaround them, but invest in the future:
upgrade to Python 3!
Maybe so -- but we are either maintaining 2.7
On Thu, Nov 14, 2013 at 09:09:06PM -0500, Terry Reedy wrote:
1.5 was around for a long time; not sure if it is completely gone yet.
It's not. I forget the details, but after the last American PyCon,
somebody posted a message about a fellow they met who was still using
1.5 in production.
--
On Thu, Nov 14, 2013 at 04:02:17PM -0800, Chris Barker wrote:
On Thu, Nov 14, 2013 at 1:55 PM, Tres Seaver tsea...@palladion.com wrote:
Fixing any bug is changing behavior; 2.7 is not frozen for bugfixes.
Thank you.
The real question is whether third-party code will break when the
On 11/14/2013 7:41 PM, Chris Barker wrote:
On Thu, Nov 14, 2013 at 3:58 PM, Steven D'Aprano st...@pearwood.info wrote:
It's not a given that the current behaviour *is* a bug.
I'll concede that it's not a bug unless someone said somewhere that
unicode messages should work
In particular,
On 14Nov2013 15:57, Chris Barker - NOAA Federal chris.bar...@noaa.gov wrote:
(amazing to me how many people are still using =2.7, actually, even
for new projects .. thank you Red Hat Enterprise Linux ;-) )
Well, one of the things RHEL gets you is platform stability (they
backport fixes;
On 15Nov2013 14:08, Steven D'Aprano st...@pearwood.info wrote:
On Thu, Nov 14, 2013 at 04:02:17PM -0800, Chris Barker wrote:
right -- any bugfix changes behaviour
It isn't clear that this is a bug at all.
Non-ascii Unicode strings are just a special case of the more general
problem of
On Fri, Nov 15, 2013 at 02:28:48PM +1100, Cameron Simpson wrote:
Non-ascii Unicode strings are just a special case of the more general
problem of what to do if printing the exception raises. If
str(exception.message) raises, suppressing the message seems like a
perfectly reasonable
26 matches
Mail list logo
