Re: [Python-Dev] One more cherry-pick request for 3.4.0 that I'd like a little public debate on
On 02/22/2014 03:27 AM, Antoine Pitrou wrote: 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. Yes, I read the reply by Charles-François. I was interested in seeing more opinions. However, nobody seems to be stepping up with any, so I'll assume for now it can be left unpicked. //arry/ ___ Python-Dev mailing list [email protected] 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
On Sat, 22 Feb 2014 20:48:04 -0800 Ethan Furman wrote: > 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. You can't encode bytes, so it should be "ASCII-encoded text" ;-) Regards Antoine. ___ Python-Dev mailing list [email protected] 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
On Sat, 22 Feb 2014 17:56:50 -0800 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. Why is "%a" here? I don't remember: was this discussed before? "Intended as a debugging aid" sounds like a weak justification to me. Regards Antoine. ___ Python-Dev mailing list [email protected] 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
Hi, First, this is a warning in reST syntax: System Message: WARNING/2 (pep-0461.txt, line 53) > 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. You may give some examples here: HTTP (Latin1 headers, binary body), SMTP, FTP, etc. > 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. IMO you should give the exhaustive list here and we should only support one formatter for integers: %d. Python 2 supports "%d", "%u" and "%i" with "%u" marked as obsolete. Python 3.5 should not reintroduce obsolete formatters. If you want to use the same code base for Python 2.6, 2.7 and 3.5: modify your code to only use %d. Same rule apply for 2to3 tool: modify your source code to be compatible with Python 3. Please also mention all flags: #, +, -, '0', ' '. > ``%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``. I'm not sure that supporting bytes argument of 1 byte is useful, but it should not be hard to implement and may be convinient. > ``%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`` Hum, you may mention that bytes(n: int) creates a bytes string of n null bytes, but b'%s' % 123 will raise an error because int.__bytes__() is not defined. Just to be more explicit. > ``%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. (You forgot "/U" representation (it's an antislah, but I don't see the key on my Mac keyboard?).) What is the use case of this *new* formatter? How do you use it? print(b'%a" % 123) may emit a BytesWarning and may lead to bugs. IMO %a should be restricted for str%args. > It has been suggested to use ``%b`` for bytes as well as ``%s``. PyArg_ParseTuple() uses %y format for the exact bytes type. > > - 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. IMO it's useless, b'%s' % bytes just work fine in Python 2 and Python 3. -- I would like to help you to implement the PEP. IMO we should share as much code as possible with PyUnicodeObject. Something using the stringlib and maybe a new PyBytesWriter API which would have an API close to PyUnicodeWriter API. We should also try to share code between PyBytes_Format() and PyBytes_FromFormat(). Victor ___ Python-Dev mailing list [email protected] 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
On 23Feb2014 16:31, Nick Coghlan wrote:
> 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 :)
Hmm. Isn't:
("%x" % val).encode("ascii")
sufficient here?
I still think that the term ASCII should appear in the prose, rather
than forcing the reader to decode the above. Example, shoehorning
off Ethan's response:
The substituted bytes will be an ASCII encoding of the corresponding str
formatting codes. Specificaly, for any numeric formatting code "%x":
b"%x" % val
is equivalent to:
("%x" % val).encode("ascii")
That ticks my wishes and includes Nick's explicit algorithmic
expression of the process.
Cheers,
--
Cameron Simpson
Me, I'm looking for obituaries. Lately a gratifyingly large number of my
most odious near-contemporaries are achieving their long-deserved quietus.
Not enough, and not always the right ones, but their time will come.
Peeve: I may not live to see them dead.
- Lee Rudolph, [email protected]
___
Python-Dev mailing list
[email protected]
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
On 23Feb2014 12:30, Victor Stinner wrote: > > 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. > > IMO you should give the exhaustive list here and we should only > support one formatter for integers: %d. Python 2 supports "%d", "%u" > and "%i" with "%u" marked as obsolete. Python 3.5 should not > reintroduce obsolete formatters. If you want to use the same code base > for Python 2.6, 2.7 and 3.5: modify your code to only use %d. Same > rule apply for 2to3 tool: modify your source code to be compatible > with Python 3. > Please also mention all flags: #, +, -, '0', ' '. Is this really necessary? Can't one just refer the the str %-formatting section of the doco? By section and title to make it easy to find. I think this should just refer the reader to the str %-formatting doco for the numeric codes and their meanings, along with the flags. Otherwise the PEP will get unreadable, to no value that I can see. If we include Nick's equivalent code example, there is no ambiguity or vagueness. I'm against restricting to just %d for int too; if the current Python supports others (eg %o, %x) for str, so should this PEP for bytes. > > ``%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``. > > I'm not sure that supporting bytes argument of 1 byte is useful, but > it should not be hard to implement and may be convinient. I'm +0.5 for a bytes argument of length 1; while bytes are arrays of small ints, just as str has no distinct "char" type a bytes has no distinct byte type. With a string we commonly use s str of length 1 to denote a single character in isolation; the same programming idioms will get you a bytes of length 1 in situations when you mean a byte. > (You forgot "/U" representation (it's an antislah, but I don't > see the key on my Mac keyboard?).) My Mac has one above the "return" key. Um, non-English locale? Curious. Cheers, -- Cameron Simpson 16 October. I also asked Anthea how many mature oaks she thought it would have taken to build a top-of-the-line ship in Nelson's day. She guessed ten. The astonishing answer (from Brewer's) is about 3,500 - 900 acres of oak forest. She said, "I wonder what we're doing now that's as wasteful as that". I said it's still called Defence. - Brian Eno, _A Year With Swollen Appendices_ ___ Python-Dev mailing list [email protected] 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
On Sun, 23 Feb 2014, Nick Coghlan wrote: Note that mandatory parentheses means we can duck the precedence question entirely, which I count as another point in favour of requiring them :) Careful, if you take that too far then Python 4 will have to be Scheme. ;-) Isaac Morland CSCF Web Guru DC 2619, x36650 WWW Software Specialist ___ Python-Dev mailing list [email protected] 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 writes: > Example:: > >>>> b'%4x' % 10 >b' a' > >>>> '%#4x' % 10 >' 0xa' > >>>> '%04X' % 10 >'000A' Shouldn't the second two examples also be bytes, ie. b'%#4x' instead of '%#4x'? 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 [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.3.5 release candidate 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm happy to announce the release of Python 3.3.5, release candidate 1. Python 3.3.5 includes a fix for a regression in zipimport in 3.3.4 (see http://bugs.python.org/issue20621) and a few other bugs. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in the 3.3 series, see http://docs.python.org/3.3/whatsnew/3.3.html To download Python 3.3.5 visit: http://www.python.org/download/releases/3.3.5/ This is a preview release, please report any bugs to http://bugs.python.org/ The final release is scheduled one week from now. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlMKIPEACgkQN9GcIYhpnLCjXACfQwbC/eD/lhKAZ+XCwTwYPVWj GMwAnjWkbdk7hqsKoh12EiagpGApEPSA =2BCx -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] 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, 21.02.2014 04:15: > Just as PEP 308 introduced a means of value-based conditions in an > expression, this system allows exception-based conditions to be used > as part of an expression. > [...] > This currently works:: > > lst = [1, 2, None, 3] > value = lst[2] or "No value" > > The proposal adds this:: > > lst = [1, 2] > value = lst[2] except IndexError: "No value" I see a risk of interfering with in-place assignment operators, e.g. x /= y except ZeroDivisionError: 1 might not do what one could expect, because (as I assume) it would behave differently from x = x / y except ZeroDivisionError: 1 I think that falls under the "overly broad exception handling" issue. If you want to include the assignment, you'll have to spell out the try-except block yourself. I find the difference in the two behaviours very unfortunate, though. This also reduces the scope of applicability somewhat. Cython has typed assignments, so a straight forward idea would be to handle TypeErrors in assignments like this: cdef str s s = x except TypeError: str(x) However, I guess that would similarly counter the idea of exception handling in an *expression*, and the correct and non-ambiguous way to do this would be to spell out the try-except block. Summing it up, my impression is that it helps some use cases but leaves others more ambiguous/unclear/unfortunate, which makes me lean towards rejecting it. Stefan ___ Python-Dev mailing list [email protected] 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
Stefan Behnel, 23.02.2014 19:51:
> Cython has typed
> assignments, so a straight forward idea would be to handle TypeErrors in
> assignments like this:
>
> cdef str s
> s = x except TypeError: str(x)
Similar code in Python would be this:
from array import array
x = array('i', [1,2,3])
value = "123"
x[0] = value except TypeError: int(value)
> However, I guess that would similarly counter the idea of exception
> handling in an *expression*, and the correct and non-ambiguous way to do
> this would be to spell out the try-except block.
Stefan
___
Python-Dev mailing list
[email protected]
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
On Feb 23, 2014 7:52 PM, "Stefan Behnel" wrote: > > Chris Angelico, 21.02.2014 04:15: > > Just as PEP 308 introduced a means of value-based conditions in an > > expression, this system allows exception-based conditions to be used > > as part of an expression. > > [...] > > This currently works:: > > > > lst = [1, 2, None, 3] > > value = lst[2] or "No value" > > > > The proposal adds this:: > > > > lst = [1, 2] > > value = lst[2] except IndexError: "No value" > > I see a risk of interfering with in-place assignment operators, e.g. > > x /= y except ZeroDivisionError: 1 > > might not do what one could expect, because (as I assume) it would behave > differently from > > x = x / y except ZeroDivisionError: 1 Yes. Augmented assignment is still assignment, so a statement. The only way to parse that is as x /= (y except ZeroDivisionError: 1) and it'd be equivalent to x = x / (y except ZeroDivisionError: 1) (If the parentheses are mandatory that makes it easier to spot the difference.) > > I think that falls under the "overly broad exception handling" issue. If > you want to include the assignment, you'll have to spell out the try-except > block yourself. I find the difference in the two behaviours very > unfortunate, though. > > This also reduces the scope of applicability somewhat. Cython has typed > assignments, so a straight forward idea would be to handle TypeErrors in > assignments like this: > > cdef str s > s = x except TypeError: str(x) > > However, I guess that would similarly counter the idea of exception > handling in an *expression*, and the correct and non-ambiguous way to do > this would be to spell out the try-except block. > > Summing it up, my impression is that it helps some use cases but leaves > others more ambiguous/unclear/unfortunate, which makes me lean towards > rejecting it. > > Stefan > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/thomas%40python.org ___ Python-Dev mailing list [email protected] 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
On 02/23/2014 03:31 AM, Antoine Pitrou wrote: On Sat, 22 Feb 2014 20:48:04 -0800 Ethan Furman wrote: 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. You can't encode bytes, so it should be "ASCII-encoded text" ;-) Good point, thanks. -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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
On 02/22/2014 10:50 PM, Nikolaus Rath wrote: Ethan Furman writes: Example:: >>> b'%4x' % 10 b' a' >>> '%#4x' % 10 ' 0xa' >>> '%04X' % 10 '000A' Shouldn't the second two examples also be bytes, ie. b'%#4x' instead of '%#4x'? Yup, thanks. -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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
On 02/23/2014 03:33 AM, Antoine Pitrou wrote: On Sat, 22 Feb 2014 17:56:50 -0800 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. Why is "%a" here? I don't remember: was this discussed before? "Intended as a debugging aid" sounds like a weak justification to me. https://mail.python.org/pipermail/python-dev/2014-January/131808.html The idea being if we offer %a, folks won't be tempted to abuse __bytes__. -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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
On 02/23/2014 03:30 AM, Victor Stinner wrote: First, this is a warning in reST syntax: System Message: WARNING/2 (pep-0461.txt, line 53) Yup, fixed that. 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. You may give some examples here: HTTP (Latin1 headers, binary body), SMTP, FTP, etc. 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. IMO you should give the exhaustive list here and we should only support one formatter for integers: %d. Python 2 supports "%d", "%u" and "%i" with "%u" marked as obsolete. Python 3.5 should not reintroduce obsolete formatters. If you want to use the same code base for Python 2.6, 2.7 and 3.5: modify your code to only use %d. Same rule apply for 2to3 tool: modify your source code to be compatible with Python 3. A link is provided to the exhaustive list. Including it verbatim here detracts from the overall readablity. I agree that having only one decimal format code would be nice, or even two if the second one did something different, and that three seems completely over the top -- unfortunately, Python 3.4 still supports all three (%d, %i, and %u). Not supporting two of them would just lead to frustration. There is also no reason to exclude %o nor %x and making the programmer reach for oct() and hex(). We're trying to simplify %-interpolation, not garner exclamations of "What were they thinking?!?" ;) ``%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`` Hum, you may mention that bytes(n: int) creates a bytes string of n null bytes, but b'%s' % 123 will raise an error because int.__bytes__() is not defined. Just to be more explicit. I added a line stating that %s does not accept numbers, but I'm not sure how bytes(n: int) is relevant? ``%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. (You forgot "/U" representation (it's an antislah, but I don't see the key on my Mac keyboard?).) Hard to forget what you don't know. ;) Will ascii() ever emit an antislash representation? What is the use case of this *new* formatter? How do you use it? An aid to debugging -- need to see what's what at that moment? Toss it into %a. It is not intended for production code, but is included to hopefully circumvent the inappropriate use of __bytes__ methods on classes. print(b'%a" % 123) may emit a BytesWarning and may lead to bugs. Why would it emit a BytesWarning? I would like to help you to implement the PEP. IMO we should share as much code as possible with PyUnicodeObject. Something using the stringlib and maybe a new PyBytesWriter API which would have an API close to PyUnicodeWriter API. We should also try to share code between PyBytes_Format() and PyBytes_FromFormat(). Thanks. I'll holler when I get that far. :) -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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
On Sun, 23 Feb 2014 12:42:59 -0800 Ethan Furman wrote: > On 02/23/2014 03:33 AM, Antoine Pitrou wrote: > > On Sat, 22 Feb 2014 17:56:50 -0800 > > 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. > > > > Why is "%a" here? I don't remember: was this discussed before? > > "Intended as a debugging aid" sounds like a weak justification to me. > > https://mail.python.org/pipermail/python-dev/2014-January/131808.html > > The idea being if we offer %a, folks won't be tempted to abuse __bytes__. Which folks are we talking about? This sounds gratuitous. Also, I don't understand what debugging is supposed to be in the context of bytes formatting. You print debugging output to a text stream, not a bytes stream. And you certainly *don't* print debugging output into a wire protocol. Regards Antoine. ___ Python-Dev mailing list [email protected] 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
On 02/23/2014 11:26 AM, Thomas Wouters wrote: On Feb 23, 2014 7:52 PM, "Stefan Behnel" mailto:[email protected]>> wrote: Chris Angelico, 21.02.2014 04:15: > Just as PEP 308 introduced a means of value-based conditions in an > expression, this system allows exception-based conditions to be used > as part of an expression. > [...] > This currently works:: > > lst = [1, 2, None, 3] > value = lst[2] or "No value" > > The proposal adds this:: > > lst = [1, 2] > value = lst[2] except IndexError: "No value" I see a risk of interfering with in-place assignment operators, e.g. x /= y except ZeroDivisionError: 1 might not do what one could expect, because (as I assume) it would behave differently from x = x / y except ZeroDivisionError: 1 Yes. Augmented assignment is still assignment, so a statement. The only way to parse that is as x /= (y except ZeroDivisionError: 1) Well, that is certainly not what I would have expected. I can also see how parentheses can help, but I still would like them optional. -- ~Ethan~ ___ Python-Dev mailing list [email protected] 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
On Mon, Feb 24, 2014 at 6:26 AM, Thomas Wouters wrote: >> I see a risk of interfering with in-place assignment operators, e.g. >> >> x /= y except ZeroDivisionError: 1 >> >> might not do what one could expect, because (as I assume) it would behave >> differently from >> >> x = x / y except ZeroDivisionError: 1 > > Yes. Augmented assignment is still assignment, so a statement. The only way > to parse that is as > > x /= (y except ZeroDivisionError: 1) > > and it'd be equivalent to > > x = x / (y except ZeroDivisionError: 1) > > (If the parentheses are mandatory that makes it easier to spot the > difference.) > >> >> I think that falls under the "overly broad exception handling" issue. If >> you want to include the assignment, you'll have to spell out the >> try-except >> block yourself. I find the difference in the two behaviours very >> unfortunate, though. Thomas's analysis is correct. It's not overly broad; in fact, what you have is an overly _narrow_ exception handler, catching a ZeroDivisionError from the evaluation of y only. ChrisA ___ Python-Dev mailing list [email protected] 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
> > >>> >> (You forgot "/U" representation (it's an antislah, but I don't >> see the key on my Mac keyboard?).) >> > > Hard to forget what you don't know. ;) Will ascii() ever emit an > antislash representation? Try ascii(chr(0x1f)). What is the use case of this *new* formatter? How do you use it? >> > > An aid to debugging -- need to see what's what at that moment? Toss it > into %a. It is not intended for production code, but is included to > hopefully circumvent the inappropriate use of __bytes__ methods on classes. How do you plan to use this output? Write it into a socket or a file? When I debug, I use print & logging which both expect text string. So I think that b'%a' is useless. > print(b'%a" % 123) may emit a BytesWarning and may lead to bugs. >> > > Why would it emit a BytesWarning? Because print expects a text string, and print(bytes) does an implicit conversion to Unicode. Try: python -bb -c "print(b'hello')". Victor ___ Python-Dev mailing list [email protected] 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
On Sun, 23 Feb 2014 14:14:55 -0800 Glenn Linderman wrote: > On 2/23/2014 1:37 PM, Antoine Pitrou wrote: > > And you certainly*don't* print debugging output into a wire protocol. > > Web server applications do, so they can be displayed in the browser. They may embed debugging information into some HTML code, which then will be sent over the wire. However, usually they don't print debugging output directly into HTTP. Regards Antoine. ___ Python-Dev mailing list [email protected] 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
On 2/23/2014 1:37 PM, Antoine Pitrou wrote: And you certainly*don't* print debugging output into a wire protocol. Web server applications do, so they can be displayed in the browser. ___ Python-Dev mailing list [email protected] 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
On 24 Feb 2014 07:39, "Antoine Pitrou" wrote: > > On Sun, 23 Feb 2014 12:42:59 -0800 > Ethan Furman wrote: > > On 02/23/2014 03:33 AM, Antoine Pitrou wrote: > > > On Sat, 22 Feb 2014 17:56:50 -0800 > > > 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. > > > > > > Why is "%a" here? I don't remember: was this discussed before? > > > "Intended as a debugging aid" sounds like a weak justification to me. > > > > https://mail.python.org/pipermail/python-dev/2014-January/131808.html > > > > The idea being if we offer %a, folks won't be tempted to abuse __bytes__. > > Which folks are we talking about? This sounds gratuitous. It's a harm containment tactic, based on the assumption people *will* want to include the output of ascii() in binary protocols containing ASCII segments, regardless of whether or not we consider their reasons for doing so to be particularly good. If %a exists, then the path of least resistance to doing this only affects the format string, and it can handle arbitrary types (except bytes under -b and -bb). By contrast, if %a doesn't exist, then it becomes more attractive to use %s in the format string and define an ASCII assuming __bytes__ implementation on a custom type. That latter scenario is substantially more problematic, since __bytes__ implementations assuming ASCII compatibility is categorically wrong, while embedding an ASCII representation in a binary protocol that includes ASCII compatible segments is merely a bit strange. Cheers, Nick. > > Also, I don't understand what debugging is supposed to be in the > context of bytes formatting. You print debugging output to a text > stream, not a bytes stream. And you certainly *don't* print debugging > output into a wire protocol. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] 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
On 23Feb2014 22:56, Victor Stinner wrote: > > An aid to debugging -- need to see what's what at that moment? Toss it > > into %a. It is not intended for production code, but is included to > > hopefully circumvent the inappropriate use of __bytes__ methods on classes. > > How do you plan to use this output? Write it into a socket or a file? > When I debug, I use print & logging which both expect text string. So I > think that b'%a' is useless. The case from the email thread, which I support at +0.5 or maybe only +0.1, is printing to a binary log. The classic example that comes to mind is syslog packets. I agree %a invites data mangling. One would hope it doesn't see use in wire protocols, only in debugging scenarios. Regrettably, syslog is such a binary logging protocol, purportedly for "text". Cheers, -- Cameron Simpson We had the experience, but missed the meaning. - T.S. Eliot ___ Python-Dev mailing list [email protected] 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
On Mon, 24 Feb 2014 08:54:08 +1000 Nick Coghlan wrote: > > > The idea being if we offer %a, folks won't be tempted to abuse > __bytes__. > > > > Which folks are we talking about? This sounds gratuitous. > > It's a harm containment tactic, based on the assumption people *will* want > to include the output of ascii() in binary protocols containing ASCII > segments But why would they? ascii() doesn't do what they want, since it's repr()-like, not str()-like. It seems your assumption is wrong. > By contrast, if %a doesn't exist, then it becomes more attractive to use %s > in the format string and define an ASCII assuming __bytes__ implementation > on a custom type. Uh... Few Python programmers would actually think of writing a __bytes__ method just to enable bytes interpolation for their custom types. However, adding "%a" as a supported interpolation format just makes things confusing for *everyone*. Regards Antoine. ___ Python-Dev mailing list [email protected] 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
On 2/23/2014 4:25 PM, Ethan Furman wrote: > I agree that having only one decimal format code would be nice, or even > two if the second one did something different, and that three seems > completely over the top -- unfortunately, Python 3.4 still supports all > three (%d, %i, and %u). Not supporting two of them would just lead to > frustration. There is also no reason to exclude %o nor %x and making > the programmer reach for oct() and hex(). We're trying to simplify > %-interpolation, not garner exclamations of "What were they > thinking?!?" ;) There are things that can be done with %o and %x that cannot be done with oct() and hex(), or at least cannot be done without a terrific amount of byte munging. For example: >>> '%#.4x' % 42 '0x002a' Not sure you'd ever need to do that in a wire protocol, but it's possible. Since one of the motivators of this feature is to make porting easier, I'd suggest fully supporting the numeric codes that are supported in 2.7. I do have some sympathy for the "change your code to a common 2.x-3.x subset" position. But since 2.7's -3 flag won't (and can't) warn you when you're doing something with %-formatting that's not support in 3.x, I think the user-friendliest approach is to support all of the numeric codes as completely as possible. Eric. ___ Python-Dev mailing list [email protected] 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
On 2/23/2014 2:25 PM, Antoine Pitrou wrote: On Sun, 23 Feb 2014 14:14:55 -0800 Glenn Linderman wrote: On 2/23/2014 1:37 PM, Antoine Pitrou wrote: And you certainly*don't* print debugging output into a wire protocol. Web server applications do, so they can be displayed in the browser. They may embed debugging information into some HTML code, which then will be sent over the wire. However, usually they don't print debugging output directly into HTTP. The HTML is sent over the wire via HTTP... that's pretty directly in the wire protocol... the HTTP headers are immediately followed by the HTML, and when the document is being generated on the fly, it may also be being encoded on the fly. I've seen it done, although I can't confirm or deny the "usually" claim you have made. ___ Python-Dev mailing list [email protected] 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
23.02.2014 19:51, Stefan Behnel wrote: I see a risk of interfering with in-place assignment operators, e.g. x /= y except ZeroDivisionError: 1 might not do what one could expect, because (as I assume) it would behave differently from x = x / y except ZeroDivisionError: 1 [snip] Please note that: x /= y if y else 0 also behaves differently from x = x / y if y else 0 Anyway, enclosing in parens would make that expicit and clear. Cheers. *j ___ Python-Dev mailing list [email protected] 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
On Mon, Feb 24, 2014 at 7:51 AM, Ethan Furman wrote: >> Yes. Augmented assignment is still assignment, so a statement. The only >> way to parse that is as >> >> x /= (y except ZeroDivisionError: 1) > > > Well, that is certainly not what I would have expected. I can see that you'd want to have that go back and redo the division with a second argument of 1, which'd look like this in statement form: try: x /= y except ZeroDivisionError: x /= 1 But, just like the decried error suppression technique, the second half of this is something that should instead be written "pass". At very least, I'd say that an except-expression where one or other of its forms is better spelled "pass" is code smell, and at worst, I'd say it's a hint that the expression form might not even be what you think it is - as in this case. Remember, this is a scope-narrowing. Where previously you had to try/except entire statements, now you can try/except just one part of something. That means you won't catch errors in the actual assignment - which is usually a good thing - but it does affect augmented assignment. My recommendation: Just use try... except pass. I'm not trying to supplant the statement form :) ChrisA ___ Python-Dev mailing list [email protected] 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
Glenn Linderman writes: > On 2/23/2014 2:25 PM, Antoine Pitrou wrote: >> On Sun, 23 Feb 2014 14:14:55 -0800 Glenn Linderman >> wrote: >>> On 2/23/2014 1:37 PM, Antoine Pitrou wrote: And you certainly*don't* print debugging output into a wire protocol. >>> Web server applications do, so they can be displayed in the browser. >> They may embed debugging information into some HTML code, which >> then will be sent over the wire. However, usually they don't >> print debugging output directly into HTTP. > The HTML is sent over the wire via HTTP... that's pretty directly > in the wire protocol... Not in the relevant sense. In a modern web framework, the HTML will typically be in internal text encoding because the framework can't know what the programmer/web developer/user will be using. So there's no need at all for PEP 461 here: you're going to be using str, and then running it through .encode() anyway. > the HTTP headers are immediately followed by the HTML, and when the > document is being generated on the fly, it may also be being > encoded on the fly. I've seen it done, although I can't confirm or > deny the "usually" claim you have made. I'm sure you've seen it done. Is it worth providing special support for it? I don't think so, and Nick's "we don't want people writing __bytes__ methods" argument sounds suspiciously like a child-proof cap to me. If people really wanna do that, let them use ascii(). ___ Python-Dev mailing list [email protected] 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
On 24 February 2014 08:56, Cameron Simpson wrote:
> On 23Feb2014 22:56, Victor Stinner wrote:
>> > An aid to debugging -- need to see what's what at that moment? Toss it
>> > into %a. It is not intended for production code, but is included to
>> > hopefully circumvent the inappropriate use of __bytes__ methods on classes.
>>
>> How do you plan to use this output? Write it into a socket or a file?
>> When I debug, I use print & logging which both expect text string. So I
>> think that b'%a' is useless.
>
> The case from the email thread, which I support at +0.5 or maybe
> only +0.1, is printing to a binary log. The classic example that
> comes to mind is syslog packets.
We actually hit a bug related to that in Beaker not that long ago - we
were interpolating (Python 2) 8-bit strings directly into the syslog
data, and it corrupted the log message when one of those strings
contained a NULL value.
Would leaving %a out destroy the utility of the PEP? No. Is leaving it
in useful? I think so, yes, as it provides OOWTD interpolation of pure
ASCII representations into binary formats that contain ASCII
compatible segments, and it's directly analogous to the handling of
the numeric formatting codes with (b"%a" % obj) being a shorthand for
(b"%s" % ("%a" % obj).encode("ascii")). (Note that invoking repr() or
ascii() on a bytes instance is perfectly legal, even under -b and -bb
- it's only str() that triggers a warning or error)
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [RELEASED] Python 3.4.0 release candidate 2 is now available
On behalf of the Python development team, I'm delighted to announce the second and final release candidate of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for mid-March 2014. The python.org web site has recently been updated to something completely new, and I'm having some difficulty updating it. For now I've made Python 3.4.0rc2 available on the legacy web site: http://legacy.python.org/download/releases/3.4.0/ Once I can update the new web site, Python 3.4.0rc2 will be available here: http://python.org/download/releases/ (I'm not sure what the final URL will be, but you'll see it listed on that page.) Please consider trying Python 3.4.0rc2 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
