[Python-Dev] Fourth (final?) preview of rc2 is up

[Larry Hastings]

Only three new revisions this time.  Victor must have taken the day off!


//arry/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Ethan Furman]

On 02/21/2014 10:57 PM, Stephen J. Turnbull wrote:

Ethan Furman writes:

On 02/21/2014 07:46 PM, Chris Angelico wrote:


but not this:

value = expr except Exception: default except Exception: default


This should be the way it works.  Nothing is gained in readability
by turning a try with multiple except statements into an
expression.


Examples have been given several times.  In general, if 'expr' is a
function call, it may well have a couple of different ways to fail
which imply different default values.

 interpolable = func(key) except TypeError: "not a string: %s" % key \
  except KeyError: "no such key: %s" % key
 print("Some message that refers to '%s' % interpolable")

versus

 try:
 interpolable = func(key)
 except TypeError:
 interpolable = "not a string: %s" % key
 except KeyError:
 interpolable = "no such key: %s" % key
 print("Some message that refers to '%s' % interpolable")

I think the latter begs to be written as the former.


Okay, that's the best example of that style I've seen so far (sorry, Chris, if something similar was in the PEP and I 
missed it).  I will yield the point that something is gained -- still, I think it is a small something compared to 
converting a nested except statement into an expression, and if only allowing one or the other makes the whole thing 
simpler I vote for the nested excepts to be converted, not the already easily read multiple excepts.


--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On Sat, 22 Feb 2014 15:57:02 +0900
"Stephen J. Turnbull"  wrote:
> 
> try:
> interpolable = func(key)
> except TypeError:
> interpolable = "not a string: %s" % key
> except KeyError:
> interpolable = "no such key: %s" % key
> print("Some message that refers to '%s' % interpolable")

I think that's a rare enough case, though (compared to the other idioms
showcased in the PEP), that we needn't care about it.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On Fri, 21 Feb 2014 09:37:29 -0800
Guido van Rossum  wrote:
> I'm put off by the ':' syntax myself (it looks to me as if someone forgot a
> newline somewhere) but 'then' feels even weirder (it's been hard-coded in
> my brain as meaning the first branch of an 'if').

Would 'else' work rather than 'then'?

Regards

Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On Sat, 22 Feb 2014 16:12:27 +0900
"Stephen J. Turnbull"  wrote:
> 
> Note in support: I originally thought that "get" methods would be more
> efficient, but since Nick pointed out that "haveattr" is implemented
> by catching the exception (Yikes! LBYL implemented by using EAFP!), I
> assume that get methods also are (explicitly or implicitly)
> implemented that way.

Well, the only way to know that a key (or attribute) exists is to do
the lookup. What else would you suggest?

And, yes, EAFP can avoid race conditions and the like (besides being
more efficient with non-trivial keys).

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On Fri, 21 Feb 2014 19:49:20 -0700
Eric Snow  wrote:
> On Fri, Feb 21, 2014 at 7:07 PM, Victor Stinner
>  wrote:
> >> Consider this example of a two-level cache::
> >> for key in sequence:
> >> x = (lvl1[key] except KeyError: (lvl2[key] except KeyError: 
> >> f(key)))
> >> # do something with x
> >
> > ... but I don't like when it is used to build complex expressions.
> 
> This is true of any expression syntax, not just this proposal--though
> some expression syntax is more apt to be abused than others: you won't
> see many multiline int literals! ;)

But this is precisely why Python has refrained from making everything
an expression. For example, why assignements are not expressions.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] One more cherry-pick request for 3.4.0 that I'd like a little public debate on

[Antoine Pitrou]

On Sat, 22 Feb 2014 01:42:57 -0600
Larry Hastings  wrote:
> 
> Victor has asked me to cherry-pick 180e4b678003:
> 
> http://bugs.python.org/issue20320  (original issue)
> http://hg.python.org/cpython/rev/180e4b678003/  (checkin into trunk)
> http://bugs.python.org/issue20646  (cherry-pick request)
> 
> This revision changes the rounding behavior of fractional-second 
> timeouts for select.select and select.kqueue.  I don't have enough 
> context to judge whether or not this is bad enough to warrant 
> cherry-picking, and the discussion on the issue didn't seem to come to a 
> firm consensus.
> 
> Can I get some opinions on this?

Well, it's certainly not rc-critical. It improves a bit a fringe
behaviour that's unlikely to be noticeable by anyone in the real world.

If you look at http://bugs.python.org/issue20320, Charles-François
there explains why it's a minor issue.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

On Sat, Feb 22, 2014 at 8:20 PM, Antoine Pitrou  wrote:
> On Sat, 22 Feb 2014 16:12:27 +0900
> "Stephen J. Turnbull"  wrote:
>>
>> Note in support: I originally thought that "get" methods would be more
>> efficient, but since Nick pointed out that "haveattr" is implemented
>> by catching the exception (Yikes! LBYL implemented by using EAFP!), I
>> assume that get methods also are (explicitly or implicitly)
>> implemented that way.
>
> Well, the only way to know that a key (or attribute) exists is to do
> the lookup. What else would you suggest?
>
> And, yes, EAFP can avoid race conditions and the like (besides being
> more efficient with non-trivial keys).

Which means that, fundamentally, EAFP is the way to do it. So if PEP
463 expressions had existed from the beginning, hasattr() probably
wouldn't have been written - people would just use an
except-expression instead.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

[Chris Angelico]

On Sat, Feb 22, 2014 at 10:57 AM, Greg Ewing
 wrote:
> Nick Coghlan wrote:
>>
>> As Chris later noted, you likely *could* still implement expression
>> local name binding for an except expression without a full closure, it
>> would just be rather difficult.
>
>
> I'm still not convinced it would be all *that* difficult.
> Seems to me it would be semantically equivalent to
> renaming the inner variable and adding a finally clause
> to unbind it. Is there something I'm missing?

An inner scope should shadow rather than unbinding. Ideally:

spam = "Initial spam"
try: 1/0
except Exception as spam:
assert isinstance(spam, Exception)
assert [spam for spam in ["List Comp"]][0] == "List Comp"
with open("test","w") as spam:
assert hasattr(spam,"write")
assert (lambda spam: spam)("Function") == "Function"
assert spam == "Initial spam"

Currently, the list comp and lambda work that way. The exception will
unbind the name, not changing the scope at all but preventing refloop
after exit. The 'with... as' works in the same scope and leaves the
name bound, which is a bit surprising in some cases (you usually end
up with a closed file object, or whatever it be, lurking around).

A clean inner-scope concept would solve all of this. The lambda would
still be a closure, because you can pass that around. All the others
would be inner scopes - shadowing cleanly and then disappearing.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On Sat, 22 Feb 2014 20:29:27 +1100
Chris Angelico  wrote:
> 
> Which means that, fundamentally, EAFP is the way to do it. So if PEP
> 463 expressions had existed from the beginning, hasattr() probably
> wouldn't have been written - people would just use an
> except-expression instead.

Really? hasattr() is much easier to write than the corresponding
except-expression.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou  wrote:
> On Sat, 22 Feb 2014 20:29:27 +1100
> Chris Angelico  wrote:
>>
>> Which means that, fundamentally, EAFP is the way to do it. So if PEP
>> 463 expressions had existed from the beginning, hasattr() probably
>> wouldn't have been written - people would just use an
>> except-expression instead.
>
> Really? hasattr() is much easier to write than the corresponding
> except-expression.

But would it be sufficiently easier to justify the creation of a
built-in? Imagine this were the other way around: we have
except-expressions, but we don't have hasattr. Now someone comes onto
python-ideas and says, "Wouldn't it be nice if we had a hasattr()
function to tell us whether something has an attribute or not".
Considering that hasattr can be easily implemented using an
except-expression, it would be unlikely to be considered worthy of a
built-in.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Thomas Wouters]

On Fri, Feb 21, 2014 at 7:46 PM, Chris Angelico  wrote:

> On Sat, Feb 22, 2014 at 9:06 AM, Greg Ewing 
> wrote:
> > Nick Coghlan wrote:
> >>
> >> On 21 February 2014 13:15, Chris Angelico  wrote:
> >>
> >>> Generator expressions require parentheses, unless they would be
> >>> strictly redundant.  Ambiguities with except expressions could be
> >>> resolved in the same way, forcing nested except-in-except trees to be
> >>> correctly parenthesized
> >>
> >>
> >> I'd like to make the case that the PEP should adopt this as its
> >> default position.
> >
> >
> > I generally agree, but I'd like to point out that this
> > doesn't necessarily mean making the parenthesizing rules as
> > strict as they are for generator expressions.
> >
> > The starting point for genexps is that the parens are part of
> > the syntax, the same way that square brackets are part of
> > the syntax of a list comprehension; we only allow them to
> > be omitted in very special circumstances.
> >
> > On the other hand, I don't think there's any harm in allowing
> > an except expression to stand on its own when there is no
> > risk of ambiguity, e.g.
> >
> >foo = things[i] except IndexError: None
> >
> > should be allowed, just as we allow
> >
> >x = a if b else c
> >
> > and don't require
> >
> >x = (a if b else c)
>
> I'm inclined to agree with you. I fought against the mandated parens
> for a long time. Would be happy to un-mandate them, as long as there's
> no way for there to be ambiguity. Is CPython able to make an operator
> non-associative? That is, to allow these:
>
> value = expr except Exception: default
> value = (expr except Exception: default) except Exception: default
> value = expr except Exception: (default except Exception: default)
>
> but not this:
>
> value = expr except Exception: default except Exception: default
>
> ?


Yes, although how to do it depends on what else 'default' and 'expr' can
be. The simple answer is to make 'expr' and 'default' be subsets of
expressions that don't include the 'except' expression themselves. Just
like how in 'A if C else B', 'A' and 'C' do not include the 'if' syntax,
but 'B' does: you need parentheses in '(a if c1 else b) if c2 else d' and
'a if (c1 if c3 else c2) else b' but not in 'a if c1 else b if c2 else d'.

However, the question becomes what to do with 'lambda' and 'if-else'. Which
of these should be valid (and mean what it means with the parentheses,
which is how the PEP currently suggests it should be; ones without
parenthesized alternatives are unambiguous, as far as I can tell.)

1. make_adder(x) except TypeError: lambda y: y + 0

2. lambda x: x + 0 except TypeError: 1
-> lambda x: (x + 0 except TypeError: 1)

3. A if f(A) except TypeError: C else B

4. f(A1) except TypeError: A2 if C else B
-> f(A1) except TypeError: (A2 if C else B)

5. f(A1) except TypeError if C else ValueError: f(A2)

6. A if C else f(B) except TypeError: B
-> (A if C else f(B)) except TypeError: B

7. f(A) except E1(A) except E2(A): E2: E1
-> f(A) except (E1(A) except E2(A): E2): E1

8. f(A) or f(B) except TypeError: f(C)
-> (f(A) or f(B)) except TypeError: f(C)

9. f(A) except TypeError: f(B) or f(C)
-> f(A) except TypeError: (f(B) or f(C))

10. A == f(A) except TypeError: B
-> (A == f(A)) except TypeError: B

11. f(A) except TypeError: A == B
-> f(A) except TypeError: (A == B)

12. A + B except TypeError: C
-> (A + B) except TypeError: C

13. f(A) except TypeError: A + B
-> f(A) except TypeError: (A + B)

#6 in particular and to some extent #4, #8 and #10 look wrong to me, so if
they'd be allowed without parentheses perhaps the precedence of if-expr and
except should be more nuanced. ('between lambda and ifexpr' is not really a
sensible way to describe precedence anyway, since despite the insistence of
the reference manual, the precedence of 'lambda' and 'ifexpr' is at best
'mixed': the grammar actually tries to match ifexpr first, but it works the
way we all expect because 'lambda' is not an infix operator.)

It's easy to disallow most of these (allowing only their parenthesized
versions), the question is where to draw the line :) Some of these require
a bit more work in the grammar, duplicating some of the grammar nodes, but
it shouldn't be too bad. However, disallowing any infix operators in the
'default' expression means it'll still be valid, just mean something
different; #9, for example, would be parsed as '(f(A) except TypeError:
f(B)) or f(C)' if the 'default' expression couldn't be an or-expression.
Disallowing it in the 'expr' expression wouldn't have that effect without
parentheses.

(FWIW, I have a working patch without tests that allows all of these, I'll
upload it tonight so people can play with it. Oh, and FWIW, currently I'm
+0 on the idea, -0 on the specific syntax.)
-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
https://mai

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On Sat, 22 Feb 2014 21:09:07 +1100
Chris Angelico  wrote:
> On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou  wrote:
> > On Sat, 22 Feb 2014 20:29:27 +1100
> > Chris Angelico  wrote:
> >>
> >> Which means that, fundamentally, EAFP is the way to do it. So if PEP
> >> 463 expressions had existed from the beginning, hasattr() probably
> >> wouldn't have been written - people would just use an
> >> except-expression instead.
> >
> > Really? hasattr() is much easier to write than the corresponding
> > except-expression.
> 
> But would it be sufficiently easier to justify the creation of a
> built-in?

Well, can you propose the corresponding except-expression?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Stephen J. Turnbull]

Antoine Pitrou writes:

 > Well, the only way to know that a key (or attribute) exists is to do
 > the lookup. What else would you suggest?

Do the lookup at the C level (or whatever the implementation language
is) and generate no exception, of course.  That's what would make it
possibly more efficient.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
> 
>  > Well, the only way to know that a key (or attribute) exists is to do
>  > the lookup. What else would you suggest?
> 
> Do the lookup at the C level (or whatever the implementation language
> is) and generate no exception, of course.  That's what would make it
> possibly more efficient.

Let's see:
- hasattr() does the lookup at the C level, and silences the
AttributeError
- dict.get() does the lookup at the C level, and doesn't generate an
exception

So apart from the minor inefficiency of generating and silencing the
AttributeError, those functions already do what you suggest.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

[Greg Ewing]

Chris Angelico wrote:

On Sat, Feb 22, 2014 at 10:57 AM, Greg Ewing
 wrote:


I'm still not convinced it would be all *that* difficult.
Seems to me it would be semantically equivalent to
renaming the inner variable and adding a finally clause
to unbind it. Is there something I'm missing?


An inner scope should shadow rather than unbinding.


It would. The name being unbound would be the renamed
inner one, not the one being shadowed.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

On Sat, Feb 22, 2014 at 9:17 PM, Antoine Pitrou  wrote:
> On Sat, 22 Feb 2014 21:09:07 +1100
> Chris Angelico  wrote:
>> On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou  wrote:
>> > On Sat, 22 Feb 2014 20:29:27 +1100
>> > Chris Angelico  wrote:
>> >>
>> >> Which means that, fundamentally, EAFP is the way to do it. So if PEP
>> >> 463 expressions had existed from the beginning, hasattr() probably
>> >> wouldn't have been written - people would just use an
>> >> except-expression instead.
>> >
>> > Really? hasattr() is much easier to write than the corresponding
>> > except-expression.
>>
>> But would it be sufficiently easier to justify the creation of a
>> built-in?
>
> Well, can you propose the corresponding except-expression?

It's hard to do hasattr itself without something messy - the best I
can come up with is this:

hasattr(x,"y") <-> (x.y or True except AttributeError: False)

but the bulk of uses of it are immediately before attempting to use
the attribute. Many require multiple statements, so they'd be better
done as a full try/except:

cpython/python-gdb.py:1392:
if not hasattr(self._gdbframe, 'select'):
print ('Unable to select frame: '
   'this build of gdb does not expose a
gdb.Frame.select method')
return False
self._gdbframe.select()
return True
becomes
try:
self._gdbframe.select()
return True
except AttributeError:
print ('Unable to select frame: '
   'this build of gdb does not expose a
gdb.Frame.select method')
return False

but others are clearly expressions in disguise:

Lib/aifc.py:882:
if hasattr(f, 'mode'):
mode = f.mode
else:
mode = 'rb'
becomes
mode = (f.mode except AttributeError: 'rb')

(In fact, I'm adding that one to the PEP's examples section.)

Lib/cgi.py:145:
if hasattr(fp,'encoding'):
encoding = fp.encoding
else:
encoding = 'latin-1'
becomes
encoding = (fp.encoding except AttributeError: 'latin-1')

Some could be done either way. If hasattr didn't exist, then this:

Lib/argparse.py:597:
if hasattr(params[name], '__name__'):
params[name] = params[name].__name__

could be written instead as:
params[name] = (params[name].__name__
except AttributeError: params[name])

which is similar length and doesn't require a built-in.

Some are fairly clearly asking to be done as try/except, irrespective
of this PEP:

Lib/decimal.py:449:
if hasattr(threading.current_thread(), '__decimal_context__'):
del threading.current_thread().__decimal_context__
becomes
try: del threading.current_thread().__decimal_context__
except AttributeError: pass

(also ibid:476)

Some are a bit of a mixture.

Lib/dis.py:40:
if hasattr(x, '__func__'):  # Method
x = x.__func__
if hasattr(x, '__code__'):  # Function
x = x.__code__
if hasattr(x, '__dict__'):  # Class or module
... lots more code ...

Could be done as try/except; first part could be done cleanly as an expression.

This one's not quite as clean, but if hasattr didn't exist, this could
be done either of two ways:

Lib/fileinput.py:342:
if hasattr(os, 'O_BINARY'):
mode |= os.O_BINARY
As an expression:
mode |= (os.O_BINARY except AttributeError: 0)
Or as a statement:
try: mode |= os.O_BINARY
except AttributeError: pass

This one definitely would want to be changed, and is also going in the PEP:

Lib/inspect.py:1350:
return sys._getframe(1) if hasattr(sys, "_getframe") else None
becomes
return (sys._getframe(1) except AttributeError: None)

Lib/ntpath.py:558:
# Win9x family and earlier have no Unicode filename support.
supports_unicode_filenames = (hasattr(sys, "getwindowsversion") and
  sys.getwindowsversion()[3] >= 2)
becomes
supports_unicode_filenames = (sys.getwindowsversion()[3] >= 2
  except AttributeError: False)

Another ternary-if LBYL that could become an expression-except EAFP:
Lib/pdb.py:745:
globs = self.curframe.f_globals if hasattr(self, 'curframe') else None
becomes
globs = (self.curframe.f_globals except AttributeError: None)
although that will return None if self.curframe has no f_globals.

Another nice easy one:
Lib/pickletools.py:2227:
if hasattr(data, "tell"):
getpos = data.tell
else:
getpos = lambda: None
becomes
getpos = (data.tell except AttributeError: lambda: None)

I could continue this theme, but behold, as Rose Maybud said, I have
said enough.

There are definitely cases where a local hasattr function could be
useful, but if the code were already written to use try/except or an
except-expression, there aren't many that would justify the creation
of a builtin.

ChrisA
__

Re: [Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

[Chris Angelico]

On Sat, Feb 22, 2014 at 10:01 PM, Greg Ewing
 wrote:
> Chris Angelico wrote:
>>
>> On Sat, Feb 22, 2014 at 10:57 AM, Greg Ewing
>>  wrote:
>>
>>> I'm still not convinced it would be all *that* difficult.
>>> Seems to me it would be semantically equivalent to
>>> renaming the inner variable and adding a finally clause
>>> to unbind it. Is there something I'm missing?
>>
>>
>> An inner scope should shadow rather than unbinding.
>
>
> It would. The name being unbound would be the renamed
> inner one, not the one being shadowed.

If the whole inner scope is disappearing, then there's no need to
unbind in a finally clause. The current behaviour of try/except is
exactly what you're describing, with no subscope:

Python 3.4.0rc1+ (default:9f76adbac8b7, Feb 15 2014, 20:19:30)
[GCC 4.7.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> e = 2.71828
>>> try: 1/0
... except ZeroDivisionError as e: pass
...
>>> e
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'e' is not defined

It's been unbound from the parent scope. It's not shadowed, it's
actually overwritten.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On Sat, 22 Feb 2014 22:13:58 +1100
Chris Angelico  wrote:
> >
> > Well, can you propose the corresponding except-expression?
> 
> It's hard to do hasattr itself without something messy - the best I
> can come up with is this:
> 
> hasattr(x,"y") <-> (x.y or True except AttributeError: False)

But it's not the same. hasattr() returns a boolean, not an arbitrary
value.

> try:
> self._gdbframe.select()
> return True
> except AttributeError:
> print ('Unable to select frame: '
>'this build of gdb does not expose a
> gdb.Frame.select method')
> return False

But then you can't distinguish between a missing "select" method
and an AttributeError raised by self._gdbframe.select() itself.

> but others are clearly expressions in disguise:
> 
> Lib/aifc.py:882:
> if hasattr(f, 'mode'):
> mode = f.mode
> else:
> mode = 'rb'
> becomes
> mode = (f.mode except AttributeError: 'rb')

Not significantly less wordy. Note you can already write:

   mode = getattr(f, 'mode', 'rb')

which is more concise.

> (In fact, I'm adding that one to the PEP's examples section.)
> 
> Lib/cgi.py:145:
> if hasattr(fp,'encoding'):
> encoding = fp.encoding
> else:
> encoding = 'latin-1'
> becomes
> encoding = (fp.encoding except AttributeError: 'latin-1')

Same here:

encoding = getattr(fp, 'encoding', 'latin-1')

> Some could be done either way. If hasattr didn't exist, then this:
> 
> Lib/argparse.py:597:
> if hasattr(params[name], '__name__'):
> params[name] = params[name].__name__
> 
> could be written instead as:
> params[name] = (params[name].__name__
> except AttributeError: params[name])

This makes a useless assignment if the attribute doesn't exist; it also
spans a single expression over two lines instead of having two simple
statements. It's definitely worse IMO.

> Some are fairly clearly asking to be done as try/except, irrespective
> of this PEP:
> 
> Lib/decimal.py:449:
> if hasattr(threading.current_thread(), '__decimal_context__'):
> del threading.current_thread().__decimal_context__
> becomes
> try: del threading.current_thread().__decimal_context__
> except AttributeError: pass

May hide a bug if threading.current_thread doesn't exist.

> Lib/inspect.py:1350:
> return sys._getframe(1) if hasattr(sys, "_getframe") else None
> becomes
> return (sys._getframe(1) except AttributeError: None)

May hide a bug if sys._getframe(1) itself raises AttributeError.

(etc.)

> I could continue this theme, but behold, as Rose Maybud said, I have
> said enough.

Yeah, none of these examples makes a convincing case that hasattr() is
useless, IMO.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

On Sat, Feb 22, 2014 at 10:27 PM, Antoine Pitrou  wrote:
> Yeah, none of these examples makes a convincing case that hasattr() is
> useless, IMO.

I'm not trying to make the case that it's useless. I'm trying to show
that, if it didn't exist, all of these would be written some other
way, and the case for its creation would not be terribly strong. It's
definitely of value (and as you've shown in some of those cases, its
proper use can narrow the exception-catching scope - a good thing),
but not enough to be worth blessing with a built-in function.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote:
 > > Antoine Pitrou writes:
 > > 
 > >  > Well, the only way to know that a key (or attribute) exists is to do
 > >  > the lookup. What else would you suggest?
 > > 
 > > Do the lookup at the C level (or whatever the implementation language
 > > is) and generate no exception, of course.  That's what would make it
 > > possibly more efficient.
 > 
 > Let's see:
 > - hasattr() does the lookup at the C level, and silences the
 > AttributeError
 > - dict.get() does the lookup at the C level, and doesn't generate an
 > exception
 > 
 > So apart from the minor inefficiency of generating and silencing the
 > AttributeError, those functions already do what you suggest.

But that's precisely the inefficiency I'm referring to.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Antoine Pitrou]

On sam., 2014-02-22 at 20:54 +0900, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
>  > On sam., 2014-02-22 at 19:29 +0900, Stephen J. Turnbull wrote:
>  > > Antoine Pitrou writes:
>  > > 
>  > >  > Well, the only way to know that a key (or attribute) exists is to do
>  > >  > the lookup. What else would you suggest?
>  > > 
>  > > Do the lookup at the C level (or whatever the implementation language
>  > > is) and generate no exception, of course.  That's what would make it
>  > > possibly more efficient.
>  > 
>  > Let's see:
>  > - hasattr() does the lookup at the C level, and silences the
>  > AttributeError
>  > - dict.get() does the lookup at the C level, and doesn't generate an
>  > exception
>  > 
>  > So apart from the minor inefficiency of generating and silencing the
>  > AttributeError, those functions already do what you suggest.
> 
> But that's precisely the inefficiency I'm referring to.

Sure, but complaining about inefficiencies without asserting their
significance is not very useful.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > On Sat, 22 Feb 2014 22:13:58 +1100
 > Chris Angelico  wrote:

 > > hasattr(x,"y") <-> (x.y or True except AttributeError: False)

 > But it's not the same. hasattr() returns a boolean, not an arbitrary
 > value.

I think he meant 

hasattr(x,"y") <-> (x.y and True except AttributeError: False)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Eric V. Smith]

On 2/22/2014 6:27 AM, Antoine Pitrou wrote:
> On Sat, 22 Feb 2014 22:13:58 +1100
> Chris Angelico  wrote:

>> Lib/inspect.py:1350:
>> return sys._getframe(1) if hasattr(sys, "_getframe") else None
>> becomes
>> return (sys._getframe(1) except AttributeError: None)
> 
> May hide a bug if sys._getframe(1) itself raises AttributeError.

return (sys._getframe except AttributeError: lambda i: None)(1)

Assuming I have the syntax correct, and the bindings work this way, of
course.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

On Sat, Feb 22, 2014 at 11:14 PM, Stephen J. Turnbull
 wrote:
> Antoine Pitrou writes:
>  > On Sat, 22 Feb 2014 22:13:58 +1100
>  > Chris Angelico  wrote:
>
>  > > hasattr(x,"y") <-> (x.y or True except AttributeError: False)
>
>  > But it's not the same. hasattr() returns a boolean, not an arbitrary
>  > value.
>
> I think he meant
>
> hasattr(x,"y") <-> (x.y and True except AttributeError: False)

No, I meant 'or' to ensure that an attribute holding a false value
doesn't come up false. But if you really want a boolean, just wrap it
up in bool().

My main point, though, was that most usage of hasattr is probing just
before something gets used - something like this:

if hasattr(obj, "attr"):
blah blah obj.attr
else:
maybe use a default or maybe do nothing

Some cases could become except-expressions; others could become
try/except statements. In each case, the loss would be small. I'm not
saying hasattr should be removed, just that it wouldn't have a strong
case if it didn't already exist.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tangent on class level scoping rules (was Re: PEP 463: Exception-catching expressions)

[Nick Coghlan]

On 22 Feb 2014 09:59, "Greg Ewing"  wrote:
>
> Nick Coghlan wrote:
>>
>> As Chris later noted, you likely *could* still implement expression
>> local name binding for an except expression without a full closure, it
>> would just be rather difficult.
>
>
> I'm still not convinced it would be all *that* difficult.
> Seems to me it would be semantically equivalent to
> renaming the inner variable and adding a finally clause
> to unbind it. Is there something I'm missing?

Dealing with references from nested closures is the hard part. It's not
impossible to solve, but would require introducing a new kind of scope not
previously seen in Python, which is a  rather dubious suggestion when the
existing closure semantics can typically do the job. However, we're getting
off topic for python-dev.

Cheers,
Nick.

>
> --
> Greg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Nick Coghlan]

On 22 Feb 2014 22:15, "Stephen J. Turnbull"  wrote:
>
> Antoine Pitrou writes:
>  > On Sat, 22 Feb 2014 22:13:58 +1100
>  > Chris Angelico  wrote:
>
>  > > hasattr(x,"y") <-> (x.y or True except AttributeError: False)
>
>  > But it's not the same. hasattr() returns a boolean, not an arbitrary
>  > value.
>
> I think he meant
>
> hasattr(x,"y") <-> (x.y and True except AttributeError: False)

With PEP 463, the explicit equivalent of hasattr() would be something like :

hasattr(x,"y") <-> (bool(x.y) or True except AttributeError: False)

The version Chris came up with was close, but as Antoine noted, didn't
ensure the result was always exactly True or False.

The translation isn't simple because we don't allow an "else" clause on the
except expression (and I agree with this limitation), so the first
expression needs to be one that will *evaluate* x.y, but ensure the result
of the expression is True if no exception is thrown.

However, as Chris noted in his reply, there are still cases where using
hasattr makes more sense, so the fact it *can* be written as an except
expression instead is a curiosity rather than anything with deep practical
implications.

Cheers,
Nick.

P.S. The fully general variant of "else" emulation under PEP 463:

((bool(EXPR) and False) or NO_EXC_RESULT except EXC: EXC_RESULT)

Note: never actually use this, it's effectively unreadable ;)

>
___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GSOC 2014

[NAVNEET SUMAN]

Thank you for your recommendations Jessica. I am looking forward to work
with python this gsoc.


On 22 February 2014 08:39, Jessica McKellar wrote:

> Hi Navneet,
>
> >This is my first year in gsoc. I have been working with python and
> django
> > from quite a time. One of the Gsoc proposed ideas drew my attention and i
> > would surely like to work on that.
> > I would like to work for creating a extension for idle to integrate
> > PEP8, what are the prerequisites . I have been studying  the PEP8 code
> past
> > a week. This might be useful for a quick start to this project. Please
> > guide.
>
> Thanks for your interest in CPython for Google Summer of Code!
>
> Mentor organizations haven't been selected yet (the official mentor
> list will go out on February 24th), and we are still finalizing our
> project list.
>
> In the meantime, I recommend:
>
> 1. Joining http://pythonmentors.com/
> 2. Reading through the developers guide: http://docs.python.org/devguide/
> 3. Picking and working on a ticket to get used to the workflow:
> http://bugs.python.org/
>
> In particular, it will be important to have contributed some patches
> to CPython before you apply, so I recommend focusing on that for the
> next couple of weeks. If you have questions while finding bugs and
> preparing patches, please don't hesitate to ask on the
> pythonmentors.com mailing list.
>
> Regards,
> -Jessica
>



-- 
 Thanks and Regards,

Navneet suman,
IIIT-Allahabad
+91-9305612151
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Brett Cannon]

On Fri, Feb 21, 2014 at 8:41 PM, Greg Ewing wrote:

> Ethan Furman wrote:
>
>> On 02/21/2014 03:29 PM, Greg Ewing wrote:
>>
>>  value = lst[2] except "No value" if IndexError
>>>
>>
>> It does read nicely, and is fine for the single, non-nested, case (which
>> is probably the vast majority), but how would it handle nested exceptions?
>>
>
> Hmmm, probably not very well, unless we define
>
>a except b if E1 except c if E2
>
> to mean
>
>a except (b except c if E2) if E1
>
> If E1 == E2, that could perhaps be abbreviated to
>
>a except b except c if E
>
> Or we could just decide that the nested case is going
> to be so rare it's not worth worrying about.


+1 on not caring. Keep the expression for simple, obvious cases of a single
exception type and fall back to the statement for fancier use (just like
listcomps). The focus should be ease of expressiveness for a common
pattern, not trying to convert tons of try/except statements into an
expression just because we can.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Brett Cannon]

On Sat, Feb 22, 2014 at 4:13 AM, Antoine Pitrou  wrote:

> On Fri, 21 Feb 2014 09:37:29 -0800
> Guido van Rossum  wrote:
> > I'm put off by the ':' syntax myself (it looks to me as if someone
> forgot a
> > newline somewhere) but 'then' feels even weirder (it's been hard-coded in
> > my brain as meaning the first branch of an 'if').
>
> Would 'else' work rather than 'then'?
>

thing = stuff['key'] except KeyError else None

That reads to me like the exception was silenced and only if there is no
exception the None is returned, just like an 'else' clause on a 'try'
statement.

I personally don't mind the 'then' as my brain has been hard-coded to mean
"the first branch of a statement" so it's looser than being explicitly
associated with 'if' but with any multi-clause statement.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Jeff Allen]

On 22/02/2014 16:36, Brett Cannon wrote:


On Sat, Feb 22, 2014 at 4:13 AM, Antoine Pitrou > wrote:


On Fri, 21 Feb 2014 09:37:29 -0800
Guido van Rossum mailto:gu...@python.org>> wrote:
> I'm put off by the ':' syntax myself (it looks to me as if
someone forgot a
> newline somewhere) but 'then' feels even weirder (it's been
hard-coded in
> my brain as meaning the first branch of an 'if').

Would 'else' work rather than 'then'?


thing = stuff['key'] except KeyError else None

That reads to me like the exception was silenced and only if there is 
no exception the None is returned, just like an 'else' clause on a 
'try' statement.


I personally don't mind the 'then' as my brain has been hard-coded to 
mean "the first branch of a statement" so it's looser than being 
explicitly associated with 'if' but with any multi-clause statement.


I read *except* as 'except if', and *:* as 'then' (often), so the main 
proposal reads naturally to me.  I'm surprised to find others don't 
also, as that's the (only?) pronunciation that makes the familiar 
if-else and try-except constructs approximate English.


Isn't adding a new keyword (*then*) likely to be a big deal? There is 
the odd example of its use as an identifier, just in our test code:

http://hg.python.org/cpython/file/0695e465affe/Lib/test/test_epoll.py#l168
http://hg.python.org/cpython/file/0695e465affe/Lib/test/test_xmlrpc.py#l310

Jeff Allen
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Tim Delaney]

On 23 February 2014 02:29, Nick Coghlan  wrote:

> On 22 Feb 2014 22:15, "Stephen J. Turnbull"  wrote:
> > Antoine Pitrou writes:
> >  > Chris Angelico  wrote:
> >  > > hasattr(x,"y") <-> (x.y or True except AttributeError: False)
> >  > But it's not the same. hasattr() returns a boolean, not an arbitrary
> >  > value.
> > I think he meant
> > hasattr(x,"y") <-> (x.y and True except AttributeError: False)
>
> With PEP 463, the explicit equivalent of hasattr() would be something like
> :
>
> hasattr(x,"y") <-> (bool(x.y) or True except AttributeError: False)
>
That would work, but I think I'd prefer:

hasattr(x,"y") <-> bool(x.y or True except AttributeError: False)

Makes it clearer IMO that the entire expression will always return a
boolean.

If exception expressions already existed in the language, I would think
there would be a strong argument for a library function hasattr(), but
probably not a builtin.

Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Nikolaus Rath]

"Stephen J. Turnbull"  writes:
> Ethan Furman writes:
>  > On 02/21/2014 07:46 PM, Chris Angelico wrote:
>  > >
>  > > but not this:
>  > >
>  > > value = expr except Exception: default except Exception: default
>  > 
>  > This should be the way it works.  Nothing is gained in readability
>  > by turning a try with multiple except statements into an
>  > expression.
>
> Examples have been given several times.  In general, if 'expr' is a
> function call, it may well have a couple of different ways to fail
> which imply different default values.
>
> interpolable = func(key) except TypeError: "not a string: %s" % key \
>  except KeyError: "no such key: %s" % key
> print("Some message that refers to '%s' % interpolable")
>
> versus
>
> try:
> interpolable = func(key)
> except TypeError:
> interpolable = "not a string: %s" % key
> except KeyError:
> interpolable = "no such key: %s" % key
> print("Some message that refers to '%s' % interpolable")

I think the following suggestion from elsewhere in the thread would look
even better in this case:

 interpolable = func(key) except (TypeError: "not a string: %s" % key,
  KeyError: "no such key: %s" % key)
 print("Some message that refers to '%s' % interpolable")

 
It does not require the backslash, it is shorter, and it can still be
chained:

 interpolable = func(key) except (TypeError: "not a string: %s" % key,
  KeyError: defaults[key]
  except (KeyError: "no such key: %s" % 
key))
 print("Some message that refers to '%s' % interpolable")

Best,
-Nikolaus

-- 
Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Stephen J. Turnbull]

Antoine Pitrou writes:

 > Sure, but complaining about inefficiencies without asserting their
 > significance is not very useful.

Since you completely missed the point of my post, I'll explain.  I was
in no way complaining about inefficiencies.

My point was precisely the opposite: to the extent that most 'get'
methods would be implemented in Python, even the minor inefficiency of
creating and suppressing a useless exception can't be avoided with the
LBYL of a get method, because haveattr itself is implemented by
generating and suppressing an exception.

I know that it's not a big deal[1], but it did help swing me to
positive on this PEP.


Footnotes: 
[1]  If it were, somebody would have reimplemented haveattr to avoid
generating an exception.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Thomas Wouters]

On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters  wrote:

>
>
> (FWIW, I have a working patch without tests that allows all of these, I'll
> upload it tonight so people can play with it. Oh, and FWIW, currently I'm
> +0 on the idea, -0 on the specific syntax.)
>

http://bugs.python.org/issue20739 is the patch.

-- 
Thomas Wouters 

Hi! I'm an email virus! Think twice before sending your email to help me
spread!
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Chris Angelico]

On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters  wrote:
> On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters  wrote:
>>
>> (FWIW, I have a working patch without tests that allows all of these, I'll
>> upload it tonight so people can play with it. Oh, and FWIW, currently I'm +0
>> on the idea, -0 on the specific syntax.)
>
>
> http://bugs.python.org/issue20739 is the patch.

Thanks!

You make a comment about precedence. When I wrote that up, it was
basically just "that seems about right"; whether it's equal to lambda,
equal to if/else, above both, below both, or in between, is free to be
tweaked according to what makes sense. Nobody has to date discussed
the exact precedence order, so feel free to tweak it for the benefit
of implementation.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[MRAB]

On 2014-02-23 00:09, Chris Angelico wrote:
> On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters 
> wrote:
>> On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters 
>> wrote:
>>>
>>> (FWIW, I have a working patch without tests that allows all of
>>> these, I'll upload it tonight so people can play with it. Oh, and
>>> FWIW, currently I'm +0 on the idea, -0 on the specific syntax.)
>>
>>
>> http://bugs.python.org/issue20739 is the patch.
>
> Thanks!
>
> You make a comment about precedence. When I wrote that up, it was
> basically just "that seems about right"; whether it's equal to
> lambda, equal to if/else, above both, below both, or in between, is
> free to be tweaked according to what makes sense. Nobody has to date
> discussed the exact precedence order, so feel free to tweak it for
> the benefit of implementation.
>
My feeling is that catching exceptions should have a lower precedence
than the other parts of an expression, but higher than comma, so:

A if C else B except E: D

would be parsed as:

(A if C else B) except E: D

I think that's because it's kind of replacing:

try:
_ = expr
except E:
_ = D

with the try..except enclosing the expression.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 463: Exception-catching expressions

[Nick Coghlan]

On 23 February 2014 11:11, MRAB  wrote:
> On 2014-02-23 00:09, Chris Angelico wrote:
>> On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters 
>> wrote:
>>> On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters 
>>> wrote:

 (FWIW, I have a working patch without tests that allows all of
 these, I'll upload it tonight so people can play with it. Oh, and
 FWIW, currently I'm +0 on the idea, -0 on the specific syntax.)
>>>
>>>
>>> http://bugs.python.org/issue20739 is the patch.
>>
>> Thanks!
>>
>> You make a comment about precedence. When I wrote that up, it was
>> basically just "that seems about right"; whether it's equal to
>> lambda, equal to if/else, above both, below both, or in between, is
>> free to be tweaked according to what makes sense. Nobody has to date
>> discussed the exact precedence order, so feel free to tweak it for
>> the benefit of implementation.
>>
> My feeling is that catching exceptions should have a lower precedence
> than the other parts of an expression, but higher than comma, so:
>
> A if C else B except E: D
>
> would be parsed as:
>
> (A if C else B) except E: D
>
> I think that's because it's kind of replacing:
>
> try:
> _ = expr
> except E:
> _ = D
>
> with the try..except enclosing the expression.

Note that mandatory parentheses means we can duck the precedence
question entirely, which I count as another point in favour of
requiring them :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Ethan Furman]

Greetings, all!

I think I'm about ready to ask for pronouncement for this PEP, but I would like opinions on the Open Questions question 
so I can close it.  :)


Please let me know if anything else needs tweaking.

--

PEP: 461
Title: Adding % formatting to bytes and bytearray
Version: $Revision$
Last-Modified: $Date$
Author: Ethan Furman 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2014-01-13
Python-Version: 3.5
Post-History: 2014-01-14, 2014-01-15, 2014-01-17, 2014-02-22
Resolution:


Abstract


This PEP proposes adding % formatting operations similar to Python 2's ``str``
type to ``bytes`` and ``bytearray`` [1]_ [2]_.


Rationale
=

While interpolation is usually thought of as a string operation, there are
cases where interpolation on ``bytes`` or ``bytearrays`` make sense, and the
work needed to make up for this missing functionality detracts from the overall
readability of the code.


Motivation
==

With Python 3 and the split between ``str`` and ``bytes``, one small but
important area of programming became slightly more difficult, and much more
painful -- wire format protocols [3]_.

This area of programming is characterized by a mixture of binary data and
ASCII compatible segments of text (aka ASCII-encoded text).  Bringing back a
restricted %-interpolation for ``bytes`` and ``bytearray`` will aid both in
writing new wire format code, and in porting Python 2 wire format code.


Overriding Principles
=

In order to avoid the problems of auto-conversion and Unicode exceptions
that could plague Python 2 code, :class:`str` objects will not be supported as
interpolation values [4]_ [5]_.


Proposed semantics for ``bytes`` and ``bytearray`` formatting
===

%-interpolation
---

All the numeric formatting codes (such as ``%x``, ``%o``, ``%e``, ``%f``,
``%g``, etc.) will be supported, and will work as they do for str, including
the padding, justification and other related modifiers.

Example::

   >>> b'%4x' % 10
   b'   a'

   >>> '%#4x' % 10
   ' 0xa'

   >>> '%04X' % 10
   '000A'

``%c`` will insert a single byte, either from an ``int`` in range(256), or from
a ``bytes`` argument of length 1, not from a ``str``.

Example:

>>> b'%c' % 48
b'0'

>>> b'%c' % b'a'
b'a'

``%s`` is restricted in what it will accept::

  - input type supports ``Py_buffer`` [6]_?
use it to collect the necessary bytes

  - input type is something else?
use its ``__bytes__`` method [7]_ ; if there isn't one, raise a 
``TypeError``

Examples:

>>> b'%s' % b'abc'
b'abc'

>>> b'%s' % 3.14
Traceback (most recent call last):
...
TypeError: 3.14 has no __bytes__ method, use a numeric code instead

>>> b'%s' % 'hello world!'
Traceback (most recent call last):
...
TypeError: 'hello world' has no __bytes__ method, perhaps you need to 
encode it?

.. note::

   Because the ``str`` type does not have a ``__bytes__`` method, attempts to
   directly use ``'a string'`` as a bytes interpolation value will raise an
   exception.  To use strings they must be encoded or otherwise transformed
   into a ``bytes`` sequence::

  'a string'.encode('latin-1')

``%a`` will call :func:``ascii()`` on the interpolated value's :func:``repr()``.
This is intended as a debugging aid, rather than something that should be used
in production.  Non-ascii values will be encoded to either ``\xnn`` or 
``\u``
representation.


Unsupported codes
-

``%r`` (which calls ``__repr__`` and returns a :class:`str`) is not supported.


Proposed variations
===

It was suggested to let ``%s`` accept numbers, but since numbers have their own
format codes this idea was discarded.

It has been proposed to automatically use ``.encode('ascii','strict')`` for
``str`` arguments to ``%s``.

  - Rejected as this would lead to intermittent failures.  Better to have the
operation always fail so the trouble-spot can be correctly fixed.

It has been proposed to have ``%s`` return the ascii-encoded repr when the
value is a ``str`` (b'%s' % 'abc'  --> b"'abc'").

  - Rejected as this would lead to hard to debug failures far from the problem
site.  Better to have the operation always fail so the trouble-spot can be
easily fixed.

Originally this PEP also proposed adding format-style formatting, but it was
decided that format and its related machinery were all strictly text (aka
``str``) based, and it was dropped.

Various new special methods were proposed, such as ``__ascii__``,
``__format_bytes__``, etc.; such methods are not needed at this time, but can
be visited again later if real-world use shows deficiencies with this solution.


Open Questions
==

It has been suggested to use ``%b`` for bytes as well as ``%s``.

  - Pro: clearly says 'this is bytes'; should be used for new code.

  - Con: does n

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Ethan Furman]

Sorry, found a couple more comments in a different thread.  Here's what I added:

+Objections
+==
+
+The objections raised against this PEP were mainly variations on two themes::
+
+  - the ``bytes`` and ``bytearray`` types are for pure binary data, with no
+assumptions about encodings
+  - offering %-interpolation that assumes an ASCII encoding will be an
+attractive nuisance and lead us back to the problems of the Python 2
+``str``/``unicode`` text model
+
+As was seen during the discussion, ``bytes`` and ``bytearray`` are also used
+for mixed binary data and ASCII-compatible segments: file formats such as
+``dbf`` and ``pdf``, network protocols such as ``ftp`` and ``email``, etc.
+
+``bytes`` and ``bytearray`` already have several methods which assume an ASCII
+compatible encoding.  ``upper()``, ``isalpha()``, and ``expandtabs()`` to name
+just a few.  %-interpolation, with its very restricted mini-language, will not
+be any more of a nuisance than the already existing methdods.
+
+
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Chris Angelico]

On Sun, Feb 23, 2014 at 12:56 PM, Ethan Furman  wrote:
> Open Questions
> ==
>
> It has been suggested to use ``%b`` for bytes as well as ``%s``.
>
>   - Pro: clearly says 'this is bytes'; should be used for new code.
>
>   - Con: does not exist in Python 2.x, so we would have two ways of doing
> the
> same thing, ``%s`` and ``%b``, with no difference between them.

The fact that the format string is bytes says 'this is bytes'. Also
the fact that you're explicitly encoding any strings used. I'm -1 on
having %b as a redundant duplicate of %s.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Mark Lawrence]

On 23/02/2014 02:30, Ethan Furman wrote:


+be any more of a nuisance than the already existing methdods.


Typo "methdods".

--
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.


Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.com


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Cameron Simpson]

On 22Feb2014 17:56, Ethan Furman  wrote:
> Please let me know if anything else needs tweaking.
> [...]
> This area of programming is characterized by a mixture of binary data and
> ASCII compatible segments of text (aka ASCII-encoded text).
> [...]
> %-interpolation
> 
> All the numeric formatting codes (such as ``%x``, ``%o``, ``%e``, ``%f``,
> ``%g``, etc.) will be supported, and will work as they do for str, including
> the padding, justification and other related modifiers.

I would like a single sentence here clarifying that the formatting
of numeric values uses an ASCII encoding.

It might be inferred from the earlier context, but I do not think
it can be deduced and therefore I think it should be said outright.
All the other formatting codes are quite explicit about how their
arguments transform into bytes, but the numeric codes just quietly
assume ASCII. The PEP should be blatant.

Otherwise I think the PEP is clear and reasonable.

Cheers,
-- 
Cameron Simpson 

ASCII  n s. [from the greek]  Those people who, at certain times of the year,
have no shadow at noon; such are the inhabitatants of the torrid zone.
- 1837 copy of Johnson's Dictionary
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Ethan Furman]

On 02/22/2014 07:29 PM, Mark Lawrence wrote:

On 23/02/2014 02:30, Ethan Furman wrote:


+be any more of a nuisance than the already existing methdods.


Typo "methdods".


Thanks, fixed.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Ethan Furman]

On 02/22/2014 07:47 PM, Cameron Simpson wrote:

On 22Feb2014 17:56, Ethan Furman  wrote:

Please let me know if anything else needs tweaking.
[...]
This area of programming is characterized by a mixture of binary data and
ASCII compatible segments of text (aka ASCII-encoded text).
[...]
%-interpolation

All the numeric formatting codes (such as ``%x``, ``%o``, ``%e``, ``%f``,
``%g``, etc.) will be supported, and will work as they do for str, including
the padding, justification and other related modifiers.


I would like a single sentence here clarifying that the formatting
of numeric values uses an ASCII encoding.


How's this?

All the numeric formatting codes (such as ``%x``, ``%o``, ``%e``, ``%f``,
``%g``, etc.) will be supported, and will work as they do for str, including
the padding, justification and other related modifiers.  The only difference
will be that the results from these codes will be ASCII-encoded bytes, not
unicode.

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Nick Coghlan]

On 23 February 2014 13:47, Cameron Simpson  wrote:
> On 22Feb2014 17:56, Ethan Furman  wrote:
>> Please let me know if anything else needs tweaking.
>> [...]
>> This area of programming is characterized by a mixture of binary data and
>> ASCII compatible segments of text (aka ASCII-encoded text).
>> [...]
>> %-interpolation
>>
>> All the numeric formatting codes (such as ``%x``, ``%o``, ``%e``, ``%f``,
>> ``%g``, etc.) will be supported, and will work as they do for str, including
>> the padding, justification and other related modifiers.
>
> I would like a single sentence here clarifying that the formatting
> of numeric values uses an ASCII encoding.
>
> It might be inferred from the earlier context, but I do not think
> it can be deduced and therefore I think it should be said outright.
> All the other formatting codes are quite explicit about how their
> arguments transform into bytes, but the numeric codes just quietly
> assume ASCII. The PEP should be blatant.

Specifically, I believe the PEP should state that, for the numeric codes:

b"%x" % val

is equivalent to:

b"%s" % (("%x" % val).encode("ascii"))

The rationale for including them is the unreadability of the latter form :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 2

[Nick Coghlan]

Thanks Ethan, this mostly looks excellent.

On 23 February 2014 11:56, Ethan Furman  wrote:
> ``%a`` will call :func:``ascii()`` on the interpolated value's
> :func:``repr()``.
> This is intended as a debugging aid, rather than something that should be
> used
> in production.  Non-ascii values will be encoded to either ``\xnn`` or
> ``\u``
> representation.

Is this really what is intended? It seems to me that what is needed is
to just call ascii(), which is inherently based on repr():

>>> ascii(1)
'1'
>>> ascii("1")
"'1'"
>>> ascii(b"1")
"b'1'"

The current wording in the PEP effectively suggests invoking repr()
twice, which is just weird:

>>> ascii(repr(1))
"'1'"
>>> ascii(repr("1"))
'"\'1\'"'
>>> ascii(repr(b"1"))
'"b\'1\'"'

And inconsistent with the meaning of %a in text interpolation:

>>> ("%a" % 1).encode("ascii")
b'1'

> Open Questions
> ==
>
> It has been suggested to use ``%b`` for bytes as well as ``%s``.
>
>   - Pro: clearly says 'this is bytes'; should be used for new code.
>
>   - Con: does not exist in Python 2.x, so we would have two ways of doing
> the
> same thing, ``%s`` and ``%b``, with no difference between them.

Another con is that using %b this way would be inconsistent with the
"b" numeric format code that requests binary output:

>>> format(2, "b")
'10'
>>> format(2, "#b")
'0b10'

So -1 for "%b" from me on both TOOWTDI and consistency grounds.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com