On Mon, Nov 18, 2013 at 12:15 PM, Chris Barker wrote:
> 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 documentatio
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 handle
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 happen
On Fri, Nov 15, 2013 at 5:24 AM, "Martin v. Löwis" 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 honestly, probab
On Fri, Nov 15, 2013 at 12:41 PM, Chris Barker wrote:
> On Fri, Nov 15, 2013 at 9:21 AM, 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.
>
> y
On Fri, Nov 15, 2013 at 9:21 AM, 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.
yup.
> I believe this to also be
> a bug, so I opened https://bugs.
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, p
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,
FWIW, the pure Python traceback.py module has a slightly different
(and saner) behavior:
>>> e = Exception(u"xx\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 value
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 reasona
On 15Nov2013 14:08, Steven D'Aprano 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 what to do if
On 14Nov2013 15:57, Chris Barker - NOAA Federal 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; primarily security in th
On 11/14/2013 7:41 PM, Chris Barker wrote:
On Thu, Nov 14, 2013 at 3:58 PM, Steven D'Aprano 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, what does the reference
On Thu, Nov 14, 2013 at 04:02:17PM -0800, Chris Barker wrote:
> On Thu, Nov 14, 2013 at 1:55 PM, Tres Seaver 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
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 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 3:58 PM, Steven D'Aprano 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 very odd choice to m
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 auto
On Thu, Nov 14, 2013 at 1:55 PM, Tres Seaver 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 -- any bugfix cha
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 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 en
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
bugfi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/14/2013 04:02 PM, Benjamin Peterson wrote:
> 2013/11/14 Chris Barker :
>> 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 lo
2013/11/14 Chris Barker :
> (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, (...)
In Python 2,
2013/11/14 Chris Barker :
> 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 than a totally b
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 n
26 matches
Mail list logo
