Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On Thu, Jan 16, 2014 at 08:23:13AM -0800, Ethan Furman wrote: > As I understand it, str.format will call the object's __format__. So, for > example, if I say: > > u'the value is: %d' % myNum(17) > > then it will be myNum.__format__ that gets called, not int.__format__; I seem to have misse

Re: [Python-Dev] PEP 461 updates

On 1/16/2014 9:46 PM, Nick Coghlan wrote: On 17 January 2014 11:51, Ethan Furman wrote: On 01/16/2014 05:32 PM, Greg wrote: I don't think it matters whether the internal details of that debate make sense to the rest of us. The main thing is that a consensus seems to have been reached on bytes

Re: [Python-Dev] PEP 461 updates

On 17 January 2014 11:51, Ethan Furman wrote: > On 01/16/2014 05:32 PM, Greg wrote: >> >> >> I don't think it matters whether the internal details of that >> debate make sense to the rest of us. The main thing is that >> a consensus seems to have been reached on bytes formatting >> being basically

Re: [Python-Dev] PEP 461 updates

On Fri, Jan 17, 2014 at 11:19:44AM +0900, Stephen J. Turnbull wrote: > Meta enough that I'll take Guido out of the CC. > > Nick Coghlan writes: > > > There are plenty of data formats (like SMTP and HTTP) that are > > constrained to be ASCII compatible, > > "ASCII compatible" is a technical ter

Re: [Python-Dev] PEP 461 updates

Greg wrote: > I don't think it matters whether the internal details of that > debate make sense to the rest of us. The main thing is that > a consensus seems to have been reached on bytes formatting > being basically a good thing. I've been mostly steering clear of the metaphysical and writing co

Re: [Python-Dev] Closing the Clinic output format debate (at least for now)

On 17 January 2014 08:01, Guido van Rossum wrote: > I am tired of being the only blocker. So I withdraw my preference. Do > what you all can agree on without me. I had been staying out of the debate because I haven't had time to participate in the derby yet (if nobody has claimed the builtins yet

Re: [Python-Dev] PEP 461 updates

Greg writes: > I don't think it matters whether the internal details of [the EIBTI > vs. PBP] debate make sense to the rest of us. The main thing is > that a consensus seems to have been reached on bytes formatting > being basically a good thing. I think some of it matters to the documentatio

Re: [Python-Dev] PEP 461 updates

Meta enough that I'll take Guido out of the CC. Nick Coghlan writes: > There are plenty of data formats (like SMTP and HTTP) that are > constrained to be ASCII compatible, "ASCII compatible" is a technical term in encodings, which means "bytes in the range 0-127 always have ASCII coded charact

Re: [Python-Dev] PEP 461 updates

On 01/16/2014 05:32 PM, Greg wrote: I don't think it matters whether the internal details of that debate make sense to the rest of us. The main thing is that a consensus seems to have been reached on bytes formatting being basically a good thing. And a good thing, too, on both counts! :) A f

Re: [Python-Dev] PEP 461 updates

On 17/01/2014 10:18 a.m., Terry Reedy wrote: On 1/16/2014 5:11 AM, Nick Coghlan wrote: Guido's successful counter was to point out that the parsing of the format string itself assumes ASCII compatible data, Nick's initial arguments against bytes formatting were very abstract and philosophical

Re: [Python-Dev] PEP 461 updates

On 17 Jan 2014 09:36, "Terry Reedy" wrote: > > On 1/16/2014 4:59 PM, Guido van Rossum wrote: > >> I'm getting tired of "did you understand what I said". > > > I was asking whether I needed to repeat myself, but forget that. > I was also saying that while I understand 'ascii-compatible encoding', I

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On 01/16/2014 01:08 PM, Ryan Smith-Roberts wrote: There are two classes of builtins whose signatures do not have these properties. The first is those with very weird signatures, like curses.window.addstr(). It's fine that those don't get converted, they're hopeless. Speaking as the father of

Re: [Python-Dev] PEP 461 updates

On 1/16/2014 4:59 PM, Guido van Rossum wrote: I'm getting tired of "did you understand what I said". I was asking whether I needed to repeat myself, but forget that. I was also saying that while I understand 'ascii-compatible encoding', I do not understand the notion of 'ascii-compatible data

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2014 04:08 PM, Ryan Smith-Roberts wrote: > [L]et us return to my original example, getservbyname(). Its current > signature: > > socket.getservbyname(servicename[, protocolname]) > > This is not an inspectable signature, since pure Python d

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

16.01.2014 17:33, Michael Urman wrote: On Thu, Jan 16, 2014 at 8:45 AM, Brett Cannon wrote: Fine, if you're worried about bytes.format() overstepping by implicitly calling str.encode() on the return value of __format__() then you will need __bytes__format__() to get equivalent support. Cou

Re: [Python-Dev] Closing the Clinic output format debate (at least for now)

I am tired of being the only blocker. So I withdraw my preference. Do what you all can agree on without me. On Thu, Jan 16, 2014 at 12:13 PM, Larry Hastings wrote: > > > The current tally of votes, by order of popularity: > > Side file: +6 > Buffer: +1.5 > Multiple buffers, Modified buffer, Forwa

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On Thu, Jan 16, 2014 at 1:42 AM, Terry Reedy wrote: itertools.repeat('a', -1) repeat('a', 0) itertools.repeat('a', times=-1) repeat('a') itertools.repeat('a', times=-2) repeat('a', -2) The first line is correct in both behavior and representation. The second line behavior (and correspo

Re: [Python-Dev] PEP 461 updates

On Thu, Jan 16, 2014 at 1:18 PM, Terry Reedy wrote: > On 1/16/2014 5:11 AM, Nick Coghlan wrote: > >> Guido's successful counter was to point out that the parsing of the >> format string itself assumes ASCII compatible data, > > Did you see my explanation, which I wrote in response to one of your e

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

Let me expand on the issue, and address some of the replies. The goal of Argument Clinic is to create new docstring signatures for builtins, with the following properties: 1) Useful. While one can create a signature of func(*args) and then document complex and arbitrary restrictions on what args

Re: [Python-Dev] Closing the Clinic output format debate (at least for now)

On 01/16/2014 01:24 PM, Georg Brandl wrote: Although this is neglecting the difference between +0 and -0 :) I hear LibreOffice is accepting external patches again. //arr//y/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/m

Re: [Python-Dev] Closing the Clinic output format debate (at least for now)

Am 16.01.2014 22:20, schrieb Larry Hastings: > On 01/16/2014 12:13 PM, Larry Hastings wrote: >> >> >> The current tally of votes, by order of popularity: >> >> Side file: +6 >> Buffer: +1.5 >> Multiple buffers, Modified buffer, Forward buffer: +1 >> Original: -5 >> > > I should add

Re: [Python-Dev] Closing the Clinic output format debate (at least for now)

On 01/16/2014 12:13 PM, Larry Hastings wrote: The current tally of votes, by order of popularity: Side file: +6 Buffer: +1.5 Multiple buffers, Modified buffer, Forward buffer: +1 Original: -5 I should add, that's out of a total of eleven votes cast. So the side file was a

Re: [Python-Dev] PEP 461 updates

On 1/16/2014 5:11 AM, Nick Coghlan wrote: Guido's successful counter was to point out that the parsing of the format string itself assumes ASCII compatible data, Did you see my explanation, which I wrote in response to one of your earlier posts, of why I think "the parsing of the format strin

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On 16/01/14 19:43, Larry Hastings wrote: On 01/16/2014 04:21 AM, MRAB wrote: On 2014-01-16 05:32, Larry Hastings wrote: [snip] We could add a special value, let's call it sys.NULL, whose specific semantics are "turns into NULL when passed into builtins". This would solve the problem but it's

[Python-Dev] Closing the Clinic output format debate (at least for now)

The current tally of votes, by order of popularity: Side file: +6 Buffer: +1.5 Multiple buffers, Modified buffer, Forward buffer: +1 Original: -5 However, as stated, support for "side files" will not go in unless Guido explicitly states that it's okay with him. He has not. There

Re: [Python-Dev] python code in argument clinic annotations

Larry, On January 16, 2014 at 2:58:02 PM, Larry Hastings (la...@hastings.org) wrote: > > However, the generated output is still going to be checked in > to the repository regardless. OK. Since it looks like it’s 100% accepted to commit it to the repo, then my question is moot. And again, Larry

Re: [Python-Dev] python code in argument clinic annotations

Am 16.01.2014 20:46, schrieb Yury Selivanov: > Guido, > > On Thursday, January 16, 2014, Guido van Rossum > wrote: > > On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov > > wrote: > > The whole discussion of whether clinic should write its output > > right

Re: [Python-Dev] python code in argument clinic annotations

On 01/16/2014 11:46 AM, Yury Selivanov wrote: There is just one reason for having it in C -- having it integrated in the build process, so that the generated output/sidefiles are not in the repository. It's possible to integrate Argument Clinic into the build process without rewriting it in C.

Re: [Python-Dev] python code in argument clinic annotations

On 01/16/2014 11:36 AM, Guido van Rossum wrote: On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov wrote: If we keep it strictly declarative, then, at least, we’ll have this possibility in the future. Sounds like a pretty unlikely scenario. Why would you implement clinic in C? We'll never reim

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On 01/16/2014 04:21 AM, MRAB wrote: On 2014-01-16 05:32, Larry Hastings wrote: [snip] We could add a special value, let's call it sys.NULL, whose specific semantics are "turns into NULL when passed into builtins". This would solve the problem but it's really, really awful. Would it be better

Re: [Python-Dev] python code in argument clinic annotations

Guido, On Thursday, January 16, 2014, Guido van Rossum wrote: > On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov > > wrote: > > The whole discussion of whether clinic should write its output > > right in the source file (buffered or not), or in a separate sidefile, > > started because we current

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On 01/16/2014 03:38 AM, Antoine Pitrou wrote: On Wed, 15 Jan 2014 21:55:46 -0800 Larry Hastings wrote: Passing in "None" here is inconvenient as it's an integer argument. Inconvenient for whom? The callee or the caller? The callee, specifically the C argument parsing code. (Even more speci

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/16/2014 12:32 AM, Larry Hastings wrote: > We could add a special value, let's call it sys.NULL, whose specific > semantics are "turns into NULL when passed into builtins". This would > solve the problem but it's really, really awful. That doesn

Re: [Python-Dev] python code in argument clinic annotations

On Thu, Jan 16, 2014 at 11:15 AM, Yury Selivanov wrote: > The whole discussion of whether clinic should write its output > right in the source file (buffered or not), or in a separate sidefile, > started because we currently cannot run the clinic during the build > process, since it’s written in p

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/16/2014 01:55 PM, Ethan Furman wrote: >> "Magic" methods, including __format__, are called on the type, not the >> instance. > > Yes, that's why I said `myNum(17)` and not `myNum`. Oops, apologies. I misread the code. Eric. ___ Python-Dev maili

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/16/2014 10:30 AM, Eric V. Smith wrote: On 01/16/2014 11:23 AM, Ethan Furman wrote: On 01/16/2014 06:45 AM, Brett Cannon wrote: But that's **only** because the numeric types choose to as part of their __format__() implementation; it is not inherent to str.format(). As I understand it, s

[Python-Dev] python code in argument clinic annotations

The whole discussion of whether clinic should write its output right in the source file (buffered or not), or in a separate sidefile, started because we currently cannot run the clinic during the build process, since it’s written in python. But what if, at some point, someone implements the Tools/

Re: [Python-Dev] cpython: asyncio: Fix CoroWrapper (fix my previous commit)

Yeah the confusing thing is that omitting the docstring fixes it -- the class still has a __doc__ attribute but apparently it comes from the metaclass. :-) I guess you *could* have both a class and an instance __doc__ by making a really clever descriptor, but it seems simpler to just use a comment

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On Thu, Jan 16, 2014 at 12:31 AM, Serhiy Storchaka wrote: > getattr(foo, 'bar', None) is not the same as getattr(foo, 'bar'). So None > can't be used as universal default value. Not universal, but I still think that most functions don't need to have such a subtle distinction. E.g. in the case of

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On Thu, Jan 16, 2014 at 1:42 AM, Terry Reedy wrote: > On 1/16/2014 3:31 AM, Serhiy Storchaka wrote: >> >> 16.01.14 08:05, Guido van Rossum написав(ла): >>> >>> In this specific case it's clear to me that the special-casing of >>> negative count is intentional -- presumably it emulates sequence >>>

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/16/2014 11:23 AM, Ethan Furman wrote: > On 01/16/2014 06:45 AM, Brett Cannon wrote: >> On Thu, Jan 16, 2014 at 2:51 AM, Ethan Furman wrote: >>> On 01/15/2014 06:45 AM, Brett Cannon wrote: This is why I have argued that if you specify it as "if there is a format spec specified,

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 1/16/2014 8:41 AM, Brett Cannon wrote: That's a very good catch, Michael! I think that makes sense if there is precedence. Unfortunately that bit from the PEP never made it into the documentation so I'm not sure if there is a backwards-compatibility worry. No. If __format__ is called with

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On Thu, Jan 16, 2014 at 11:13 AM, Neil Schemenauer wrote: > A TypeError exception is what we want if the object does not support > bytes formatting. Some possible problems: > > - It could be hard to provide a helpful exception message since it > is generated inside the __format__ method rather

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

Michael Urman wrote: > If __format__ receives a format_spec of type bytes, it should return > bytes. For such cases on objects that cannot support bytes (i.e. for > str), it can raise. This appears to avoid the need for additional > methods. (As does Nick's proposal of leaving it out for now.) Th

Re: [Python-Dev] PEP 461 updates

Carl Meyer wrote: > I think the PEP could really use a rationale section summarizing _why_ > these formatting operations are being added to bytes I agree. My attempt at re-writing the PEP is below. >> In order to avoid the problems of auto-conversion and >> value-generated exceptions, all objec

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On Thu, Jan 16, 2014 at 11:33 AM, Michael Urman wrote: > On Thu, Jan 16, 2014 at 8:45 AM, Brett Cannon wrote: > > Fine, if you're worried about bytes.format() overstepping by implicitly > > calling str.encode() on the return value of __format__() then you will > need > > __bytes__format__() to g

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 01/16/2014 06:45 AM, Brett Cannon wrote: On Thu, Jan 16, 2014 at 2:51 AM, Ethan Furman wrote: On 01/15/2014 06:45 AM, Brett Cannon wrote: This is why I have argued that if you specify it as "if there is a format spec specified, then the return value from calling __format__() will have str

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On Thu, Jan 16, 2014 at 8:45 AM, Brett Cannon wrote: > Fine, if you're worried about bytes.format() overstepping by implicitly > calling str.encode() on the return value of __format__() then you will need > __bytes__format__() to get equivalent support. Could we just re-use PEP-3101's note (easil

Re: [Python-Dev] cpython: asyncio: Fix CoroWrapper (fix my previous commit)

On 16.01.2014 16:57, Guido van Rossum wrote: > Because somehow you can't have a slot named __doc__ *and* a docstring > in the class. Try it. (I tried to work around this but didn't get very > far.) That's true for all class attributes. You can't have a slot and a class attribute at the same time.

Re: [Python-Dev] cpython: asyncio: Fix CoroWrapper (fix my previous commit)

Because somehow you can't have a slot named __doc__ *and* a docstring in the class. Try it. (I tried to work around this but didn't get very far.) On Thu, Jan 16, 2014 at 3:40 AM, Antoine Pitrou wrote: > On Thu, 16 Jan 2014 01:55:43 +0100 (CET) > victor.stinner wrote: >> http://hg.python.org/cpy

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

Greg Ewing wrote: > Neil Schemenauer wrote: >> Objects that implement __str__ can also implement __bytes__ if they >> can guarantee that ASCII characters are always returned, > > I think __ascii_ would be a better name. I'd expect > a method called __bytes__ on an int to return some > version of i

Re: [Python-Dev] PEP 461 updates

On 01/16/2014 04:49 AM, Michael Urman wrote: On Thu, Jan 16, 2014 at 1:52 AM, Ethan Furman wrote: Is this an intended exception to the overriding principle? Hmm, thanks for spotting that. Yes, that would be a value error if anything over 255 is used, both currently in Py2, and for bytes in

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On Thu, Jan 16, 2014 at 4:56 AM, Nick Coghlan wrote: > > On 16 Jan 2014 17:53, "Ethan Furman" wrote: > > > > On 01/15/2014 06:45 AM, Brett Cannon wrote: > >> > >> > >> This is why I have argued that if you specify it as "if there is a > format spec specified, then the return value from > >> call

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On Thu, Jan 16, 2014 at 2:51 AM, Ethan Furman wrote: > On 01/15/2014 06:45 AM, Brett Cannon wrote: > >> >> This is why I have argued that if you specify it as "if there is a format >> spec specified, then the return value from >> calling __format__() will have str.decode('ascii', 'strict') called

Re: [Python-Dev] Common subset of python 2 and python 3

On Wed, Jan 15, 2014 at 01:22:44PM +0100, "Martin v. Löwis" wrote: > Am 12.01.14 18:39, schrieb Nachshon David Armon: > >>> I propose that this new version of python use the python 3 unicode model. > >>> As the version of python will be fully compatible with both python 2 and > >>> with python 3 bu

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On 2014-01-16 05:32, Larry Hastings wrote: [snip] In the specific case of SHA1_new's "string" parameter, we could lie and claim that the default value is b''. Internally we could still use NULL as a default and get away with it. But this is only a happy coincidence. Many (most?) functions lik

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

Am 16.01.2014 12:39, schrieb Antoine Pitrou: > On Thu, 16 Jan 2014 04:42:43 -0500 > Terry Reedy wrote: > >> On 1/16/2014 3:31 AM, Serhiy Storchaka wrote: >> > 16.01.14 08:05, Guido van Rossum написав(ла): >> >> In this specific case it's clear to me that the special-casing of >> >> negative count

Re: [Python-Dev] cpython: asyncio: Fix CoroWrapper (fix my previous commit)

On Thu, 16 Jan 2014 01:55:43 +0100 (CET) victor.stinner wrote: > http://hg.python.org/cpython/rev/f07161c4f3aa > changeset: 88494:f07161c4f3aa > user:Victor Stinner > date:Thu Jan 16 01:55:29 2014 +0100 > summary: > asyncio: Fix CoroWrapper (fix my previous commit) > > Add __

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On Thu, 16 Jan 2014 04:42:43 -0500 Terry Reedy wrote: > On 1/16/2014 3:31 AM, Serhiy Storchaka wrote: > > 16.01.14 08:05, Guido van Rossum написав(ла): > >> In this specific case it's clear to me that the special-casing of > >> negative count is intentional -- presumably it emulates sequence > >>

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On Wed, 15 Jan 2014 21:55:46 -0800 Larry Hastings wrote: > > Passing in "None" here is inconvenient as it's an integer argument. Inconvenient for whom? The callee or the caller? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org htt

Re: [Python-Dev] PEP 461 updates

On 16 Jan 2014 11:45, "Carl Meyer" wrote: > > Hi Ethan, > > I haven't chimed into this discussion, but the direction it's headed > recently seems right to me. Thanks for putting together a PEP. Some > comments on it: > > On 01/15/2014 05:13 PM, Ethan Furman wrote: > >

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

Nick Coghlan wrote: I have a different proposal: let's *just* add mod formatting to bytes, and leave the extensible formatting system as a text only operation. +1 -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mai

Re: [Python-Dev] PEP 461 - Adding % and {} formatting to bytes

On 16 Jan 2014 17:53, "Ethan Furman" wrote: > > On 01/15/2014 06:45 AM, Brett Cannon wrote: >> >> >> This is why I have argued that if you specify it as "if there is a format spec specified, then the return value from >> calling __format__() will have str.decode('ascii', 'strict') called on it" yo

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

On 1/16/2014 3:31 AM, Serhiy Storchaka wrote: 16.01.14 08:05, Guido van Rossum написав(ла): In this specific case it's clear to me that the special-casing of negative count is intentional -- presumably it emulates sequence repetition, where e.g. 'a'*-1 == ''. In this specific case it's contrar

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

16.01.14 08:05, Guido van Rossum написав(ла): In this specific case it's clear to me that the special-casing of negative count is intentional -- presumably it emulates sequence repetition, where e.g. 'a'*-1 == ''. In this specific case it's contrary to sequence repetition. Because repeat('a',

Re: [Python-Dev] AC Derby and accepting None for optional positional arguments

16.01.14 07:55, Larry Hastings написав(ла): * itertools.repeat deliberately makes it impossible to provide an argument for "times" that behaves the same as not providing the "times" argument, and * there is currently no way to implement this behavior using Argument Clinic. (I'd h

[Python-Dev] Argument Clinic Derby update

The Derby is moving forward, and I have maybe a half-dozen contributors so far. They've made a small dent in making the conversion but I'd have to say it's going slowly. We could use more people contributing patches! To the contributors with patches that are stalled in the tracker: Sorry,

Re: [Python-Dev] PEP 460 reboot

On 14Jan2014 20:23, Antoine Pitrou wrote: > On Tue, 14 Jan 2014 10:52:05 -0800 > Guido van Rossum wrote: > > Quite a few people have spoken out in favor of loud > > failures rather than silent "wrong" output. But I think that in the > > specific context of formatting output, there is a long and I