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

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

Re: "More About Unicode in Python 2 and 3"

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: "More About Unicode in Python 2 and 3" Chris Angelico <rosuav@gmail.com> - 2014-01-06 00:34 +1100
    Re: "More About Unicode in Python 2 and 3" Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-06 09:56 +1100
      Re: "More About Unicode in Python 2 and 3" Chris Angelico <rosuav@gmail.com> - 2014-01-06 11:04 +1100
      Re: "More About Unicode in Python 2 and 3" Ethan Furman <ethan@stoneleaf.us> - 2014-01-05 16:13 -0800

#63191 — Re: "More About Unicode in Python 2 and 3"

On Mon, Jan 6, 2014 at 12:14 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/
>
> Please don't shoot the messenger :)

Most of that is tiresome reiterations of the same arguments ("It
worked fine, there were just a few problems" - which means that you
haven't thought through text vs bytes properly; the switch to Py3
highlights a problem that was already there, which means that Py3
showed up what was already a problem - sounds a bit like Romans 7 to
me), plus complaints that have been heard elsewhere, like the
encode/decode methods and the removal of codecs that aren't
str<->bytes. (Don't know if that one will ever be resolved, but it's
not enough to say that Python 3 "got it wrong". As we've seen from
3.3, there has been a progressive improvement in compatibility between
Py2 and Py3. Maybe 3.5 will recreate some of these things people are
moaning about the lack of, which would then prove that the Py3 model
isn't fundamentally flawed by their loss. Anyhow.)

But this bit looks odd:

"""
For instance passing a urllib request object to Flask's JSON parse
function breaks on Python 3 but works on Python 2 as a result of this:

>>> from urllib.request import urlopen
>>> r = urlopen('https://pypi.python.org/pypi/Flask/json')
>>> from flask import json
>>> json.load(r)
Traceback (most recent call last):
  File "decoder.py", line 368, in raw_decode
StopIteration

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: No JSON object could be decoded
"""

Why is a StopIteration bubbling up? (I don't have Flask, so I can't
verify this.) Is it as simple as "this should be raising from None",
or is there something else going on?

ChrisA

[toc] | [next] | [standalone]

#63237

Chris Angelico wrote:

> But this bit looks odd:
> 
> """
> For instance passing a urllib request object to Flask's JSON parse
> function breaks on Python 3 but works on Python 2 as a result of this:
> 
>>>> from urllib.request import urlopen
>>>> r = urlopen('https://pypi.python.org/pypi/Flask/json')
>>>> from flask import json
>>>> json.load(r)
> Traceback (most recent call last):
>   File "decoder.py", line 368, in raw_decode
> StopIteration
> 
> During handling of the above exception, another exception occurred:
> 
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: No JSON object could be decoded
> """

I'm not sure about the "works on Python 2" part. Is Armin just complaining
about the StopIteration being visible in Python 3 but hidden in Python 2? I
don't have Flask installed, and aren't going to install it just for this.


> Why is a StopIteration bubbling up? (I don't have Flask, so I can't
> verify this.) Is it as simple as "this should be raising from None",
> or is there something else going on?

Remember that "raise Spam from None" only works from Python 3.3 onwards.
Personally, I think that releasing nested tracebacks before having a way to
suppress the display was a strategic blunder, but it's fixed now, at least
for those who can jump straight to 3.3 and not bother supporting 3.1 and
3.2.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#63244

On Mon, Jan 6, 2014 at 9:56 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
>> Why is a StopIteration bubbling up? (I don't have Flask, so I can't
>> verify this.) Is it as simple as "this should be raising from None",
>> or is there something else going on?
>
> Remember that "raise Spam from None" only works from Python 3.3 onwards.
> Personally, I think that releasing nested tracebacks before having a way to
> suppress the display was a strategic blunder, but it's fixed now, at least
> for those who can jump straight to 3.3 and not bother supporting 3.1 and
> 3.2.

Fair enough. If it's a problem, I'm sure Flask could do something like
(untested):

error = False
try:
    next(whatever)
except StopIteration:
    error = True
if error: raise ValueError("...")

which would work across all. But that's assuming that it really is
just a small matter of traceback ugliness. The post implies that it's
a lot worse than that.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63248

On 01/05/2014 02:56 PM, Steven D'Aprano wrote:
>
> Remember that "raise Spam from None" only works from Python 3.3 onwards.
> Personally, I think that releasing nested tracebacks before having a way to
> suppress the display was a strategic blunder [...]

I would just call it really really annoying. ;)  On the upside adding 'from None' was a small enough project that I was 
able to get it going, and that was the bridge to eventually becoming a dev.  :D

--
~Ethan~

[toc] | [prev] | [standalone]

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

csiph-web