Re: [Python-Dev] chained assignment weirdity

On 11/7/2012 5:11 PM, Terry Reedy wrote: On 11/7/2012 4:39 PM, Ned Batchelder wrote: Just to be clear: the reference guide says that the behavior *SHOULD BE* (but is not yet) this: Python 3.3.0 >>> {print("a"):print("b")} a b {None: None} >>> d = {} >>> d[print("

Re: [Python-Dev] urlretrieve regression no.2, now in Python 3.3

On Wed, Nov 7, 2012 at 2:42 PM, Terry Reedy wrote: > On 11/7/2012 5:57 AM, anatoly techtonik wrote: >> >> urlretrieve has a callback parameter, which takes function with the >> following prototype: >> >>def callback(block_number, block_size, total_size): >> pass >> >> Where block_size was

Re: [Python-Dev] cpython: Issue #16218: skip test if filesystem doesn't support required encoding

On Wed, 07 Nov 2012 23:47:13 +0100, Victor Stinner wrote: > 2012/11/7 Alexandre Vassalotti : > > The Unicode code points in the U+DC00-DFFF range (low surrogate area) can't > > be encoded in UTF-8. Quoting from RFC 3629: > > > > The definition of UTF-8 prohibits encoding character numbers between

Re: [Python-Dev] cpython: Issue #16218: skip test if filesystem doesn't support required encoding

2012/11/7 Alexandre Vassalotti : > The Unicode code points in the U+DC00-DFFF range (low surrogate area) can't > be encoded in UTF-8. Quoting from RFC 3629: > > The definition of UTF-8 prohibits encoding character numbers between U+D800 > and U+DFFF, which are reserved for use with the UTF-16 encod

Re: [Python-Dev] urlretrieve regression no.2, now in Python 3.3

On 11/7/2012 5:57 AM, anatoly techtonik wrote: urlretrieve has a callback parameter, which takes function with the following prototype: def callback(block_number, block_size, total_size): pass Where block_size was constant and block_size*block_number gave an exact number of transferred

Re: [Python-Dev] chained assignment weirdity

On 08/11/12 08:39, Ned Batchelder wrote: Just to be clear: the reference guide says that the behavior *SHOULD BE* (but is not yet) this: Python 3.3.0 >> {print("a"):print("b")} a b {None: None} That was the behaviour of Python 2.4: py> def pr(x): ... print x ... py> {pr(1): pr(2), pr

Re: [Python-Dev] cpython: Issue #16218: skip test if filesystem doesn't support required encoding

The Unicode code points in the U+DC00-DFFF range (low surrogate area) can't be encoded in UTF-8. Quoting from RFC 3629 : *The definition of UTF-8 prohibits encoding character numbers between U+D800 and U+DFFF, which

Re: [Python-Dev] chained assignment weirdity

On 11/7/2012 4:39 PM, Ned Batchelder wrote: Just to be clear: the reference guide says that the behavior *SHOULD BE* (but is not yet) this: Python 3.3.0 >>> {print("a"):print("b")} a b {None: None} >>> d = {} >>> d[print("a")] = print("b") b a >>> Is

Re: [Python-Dev] chained assignment weirdity

The dict display is considered an *expression* and thus must follow the L2R rule. The assignment is explicitly covered by the R2L rule for assignments (only). Weird or not, those are the rules, and I don't want to change them. On Wed, Nov 7, 2012 at 1:39 PM, Ned Batchelder wrote: > > On 11/7/2012

Re: [Python-Dev] chained assignment weirdity

On 11/7/2012 12:08 PM, Serhiy Storchaka wrote: On 07.11.12 17:12, Nick Coghlan wrote: Since you've indicated the implementation is in the wrong here and you also want to preserve opcode semantics, I think Skip's patch is correct, but also needs to be applied to dict comprehensions (now we have

Re: [Python-Dev] chained assignment weirdity

On 11/7/2012 10:17 AM, Guido van Rossum wrote: Ok, somebody go for it! (Also please refer to my pronouncement in the bug -- I've gotta run.) Done. http://bugs.python.org/issue11205?@ok_message=msg 175120 -- Terry Jan Reedy ___ Python-Dev mailing lis

Re: [Python-Dev] chained assignment weirdity

On 11/7/2012 9:54 AM, Guido van Rossum wrote: Hm. I really don't think that is a good development for Python to compromise in the area of expression evaluation order where side effects are involved. I agreee. I think Python's simple left to right evaluation order is one of its virtues. A g

Re: [Python-Dev] chained assignment weirdity

On 07.11.12 17:12, Nick Coghlan wrote: Since you've indicated the implementation is in the wrong here and you also want to preserve opcode semantics, I think Skip's patch is correct, but also needs to be applied to dict comprehensions (now we have them). The extra bytecode is only ROT_TWO, which

Re: [Python-Dev] chained assignment weirdity

Ok, somebody go for it! (Also please refer to my pronouncement in the bug -- I've gotta run.) On Wed, Nov 7, 2012 at 7:12 AM, Nick Coghlan wrote: > On Thu, Nov 8, 2012 at 12:54 AM, Guido van Rossum > wrote: > > On Wed, Nov 7, 2012 at 4:13 AM, Ned Batchelder > wrote: > >> If the bug report is

Re: [Python-Dev] chained assignment weirdity

On Thu, Nov 8, 2012 at 12:54 AM, Guido van Rossum wrote: > On Wed, Nov 7, 2012 at 4:13 AM, Ned Batchelder wrote: >> If the bug report is accurate, CPython and the reference manual have >> disagreed since Python 2.5, and many of us are now surprised to hear it, >> which means there can't have been

Re: [Python-Dev] chained assignment weirdity

On Thu, Nov 8, 2012 at 1:54 AM, Guido van Rossum wrote: > On Wed, Nov 7, 2012 at 4:13 AM, Ned Batchelder wrote: >> We've gone out of our way to >> maintain backward compatibility with the implemented behavior before >> (ordering of dict keys, for example). > > Not sure what you're referencing her

Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"

On Wed, Nov 7, 2012 at 11:57 PM, Ulrich Eckhardt wrote: > How about: > > "UnboundLocalError: Local variable 'FONT_NAMES' (created on >line 11) referenced before assignment." > > What I don't really like is the term "created". Maybe "implicitly created on > line 11"? Or "implied by line 11"?

Re: [Python-Dev] chained assignment weirdity

On Wed, Nov 7, 2012 at 4:13 AM, Ned Batchelder wrote: > I think it's unfortunate that the current patch in the referenced bug ( > http://bugs.python.org/issue11205 ) fixes the "problem" by adding one more > bytecode to the compiled Python. The other alternative seems to be changing > the meaning

Re: [Python-Dev] chained assignment weirdity

On 7 November 2012 15:16, Chris Angelico wrote: > On Thu, Nov 8, 2012 at 1:11 AM, Nick Coghlan wrote: >> "The implementation is right, the docs are wrong" sounds good to me, >> as it's easy to justify the out of order evaluation in terms of the >> equivalent item assignment statements: > > What d

Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"

On Wed, 07 Nov 2012 14:57:57 +0100, Ulrich Eckhardt wrote: > Am 31.10.2012 23:15, schrieb Steven D'Aprano: > > On 01/11/12 06:57, anatoly techtonik wrote: > > [...] > >> UnboundLocalError: local variable 'FONT_NAMES' referenced before > >> assignment > [...] > >> I wonder if this message can be i

Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"

> How about: > > "UnboundLocalError: Local variable 'FONT_NAMES' (created on >line 11) referenced before assignment." > > What I don't really like is the term "created". Maybe "implicitly created > on line 11"? Or "implied by line 11"? Or how about "Local variable > FONT_NAMES (implied by lin

Re: [Python-Dev] chained assignment weirdity

On Thu, Nov 8, 2012 at 1:11 AM, Nick Coghlan wrote: > "The implementation is right, the docs are wrong" sounds good to me, > as it's easy to justify the out of order evaluation in terms of the > equivalent item assignment statements: What do other Pythons than CPython do currently? Or is it "The

Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"

On 7 November 2012 13:57, Ulrich Eckhardt wrote: > Am 31.10.2012 23:15, schrieb Steven D'Aprano: > I'll take a shot, since I was also bitten by this when trying to learn > Python. The important point is that some code earlier or later in that > function does an assignment, so this location should

Re: [Python-Dev] chained assignment weirdity

On Wed, Nov 7, 2012 at 10:13 PM, Ned Batchelder wrote: > There are plenty of places where different Python implementations differ, > and even careful observers had different ideas about how keys and values > were ordered in dict displays ("I thought it was like a function call," vs, > "I thought

Re: [Python-Dev] Improve error message "UnboundLocalError: local variable referenced before assignment"

Am 31.10.2012 23:15, schrieb Steven D'Aprano: On 01/11/12 06:57, anatoly techtonik wrote: [...] UnboundLocalError: local variable 'FONT_NAMES' referenced before assignment [...] I wonder if this message can be improved with a pointer to the concept on when global variables become local? If y

Re: [Python-Dev] chained assignment weirdity

On 11/6/2012 5:12 PM, Guido van Rossum wrote: On Tue, Nov 6, 2012 at 9:58 AM, Ned Batchelder wrote: On 11/6/2012 11:26 AM, R. David Murray wrote: On Tue, 06 Nov 2012 18:14:38 +0200, Serhiy Storchaka wrote: Another counterintuitive (and possible wrong) example: >>> {print('foo'): print

[Python-Dev] Fwd: [issue16424] regression: os.path.split('//hostname/foo/bar.txt')

Forwarding to python-dev. Does everybody agree that the following behavior is not a regression, but a feature of os.path.split()? Python 3: >>> import os.path as osp >>> osp.split('//hostname/foo/') ('//hostname/foo/', '') Python 2: >>> osp.split('//hostname/foo/') ('//hostname/foo', '') But P

[Python-Dev] urlretrieve regression no.2, now in Python 3.3

urlretrieve has a callback parameter, which takes function with the following prototype: def callback(block_number, block_size, total_size): pass Where block_size was constant and block_size*block_number gave an exact number of transferred bytes. Recent change in Python 3.3 changed the sem

Re: [Python-Dev] 回复： Python-Dev Digest, Vol 112, Issue 8

Hi, 2012/11/7 邓九祥 : > I hava some question about Object which "inital" need ,but return "object" > in mongo shell. So This is the python-dev mailing list, which deals with development of the Python language. You should ask your question on some MongoDB forum. > > BSONElement initial = p["initia