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

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

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

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). >

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

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). [...] %-interpol

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

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 http

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

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

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

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

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

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

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

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

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

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 % f

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

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'

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

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.

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

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 t

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

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

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

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 t

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

"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 t

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

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 ar

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

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 someo

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

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 me

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

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), bu

Re: [Python-Dev] GSOC 2014

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 id

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

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 > >

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

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 *th

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

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 arbitra

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

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

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

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 exce

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

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

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

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 whatev

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

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 ca

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

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 i

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

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 addi

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

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 t

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

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 inne

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

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 gen

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

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 effic

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

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

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

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.

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

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 - peop

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

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? hasa

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

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

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

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-pi

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

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 except

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

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

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

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 g

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

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 t

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

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 't

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

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 multi

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

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/arc