Re: [Python-Dev] PEP 461 updates

On 01/15/2014 06:12 PM, Glenn Linderman wrote: On 1/15/2014 4:13 PM, Ethan Furman wrote: - no value generated errors ... %c will insert a single byte, either from an int in range(256), or from a bytes argument of length 1. what does x = 354 b"%c" % x produce? Seems that construct prod

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

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" you get the support for the various number-specific format

Re: [Python-Dev] PEP 460 reboot

On 01/14/2014 10:58 PM, Stephen J. Turnbull wrote: At the very least, the "iterated interpolation is a bad idea" misfeature needs to be documented. I'm not sure it needs any extra attention. Even with str, iterated interpolation is tricky -- I've been bitten by it more than once, and that ev

Re: [Python-Dev] PEP 461 updates

On 01/15/2014 05:17 PM, Carl Meyer wrote: I think the PEP could really use a rationale section It will have one before it's done. Also I think it would be useful to have a section summarizing the primary objections that have been raised, and why those objections have been overruled Excell

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

On 01/15/2014 10:21 PM, Georg Brandl wrote: Am 16.01.2014 05:35, schrieb Ryan Smith-Roberts: On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts mailto:r...@lab.net>> wrote: socket.getservbyname(servicename[, protocolname]) -> socket.getservbyname(servicename, protocolname=None)

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

Am 16.01.2014 05:35, schrieb Ryan Smith-Roberts: > On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts > wrote: > > socket.getservbyname(servicename[, protocolname]) > -> > socket.getservbyname(servicename, protocolname=None) > > > Here is a more complicated exa

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

On Wed, Jan 15, 2014 at 9:55 PM, Larry Hastings wrote: > > On 01/15/2014 09:37 PM, Guido van Rossum wrote: > > Well, I think these are mostly artifacts from old times, and usually passing > None *should* be the same as omitting the argument. But check each case! > > > Vajrasky Kok's recent posting

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

On 01/15/2014 09:37 PM, Guido van Rossum wrote: Well, I think these are mostly artifacts from old times, and usually passing None *should* be the same as omitting the argument. But check each case! Vajrasky Kok's recent posting to python-dev discusses the same problem. His example is iterto

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

Well, I think these are mostly artifacts from old times, and usually passing None *should* be the same as omitting the argument. But check each case! On Wednesday, January 15, 2014, Larry Hastings wrote: > > On 01/15/2014 08:35 PM, Ryan Smith-Roberts wrote: > > On Wed, Jan 15, 2014 at 7:57 PM,

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

On 01/15/2014 08:35 PM, Ryan Smith-Roberts wrote: On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts > wrote: socket.getservbyname(servicename[, protocolname]) -> socket.getservbyname(servicename, protocolname=None) Here is a more complicated example, since t

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

On Wed, Jan 15, 2014 at 7:57 PM, Ryan Smith-Roberts wrote: > socket.getservbyname(servicename[, protocolname]) > -> > socket.getservbyname(servicename, protocolname=None) > Here is a more complicated example, since the above does technically have an alternative fix: sockobj.sendmsg(buffers[, an

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan writes: > Yes, I'm currently thinking the appropriate approach to the docs > will be to remove the current "these have most of the str methods > too" paragraph for binary sequences and instead create three > completely explicit lists of methods: > - provided, works with arbitr

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

One of the downsides of converting positional-only functions to Argument Clinic is that it can result in misleading docstring signatures. Example: socket.getservbyname(servicename[, protocolname]) -> socket.getservbyname(servicename, protocolname=None) The problem with the new signature is that i

Re: [Python-Dev] PEP 461 updates

Glenn Linderman wrote: x = 354 b"%c" % x Is this an intended exception to the overriding principle? I think it's an unavoidable one, unless we want to introduce an "integer in the range 0-255" type. But that would just push the problem into another place, since b"%c" % byte(x) would then

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

Ethan Furman wrote: Well, I'm not sure what "booted into touch" means, It's a rugby term, referring to kicking the ball over the touch line. As a metaphor, it seems to mean making a problem go away. -- Greg ___ Python-Dev mailing list Python-Dev@pyt

Re: [Python-Dev] Signature of function with default value uncapturable in Python and C

On 1/15/2014 9:25 PM, Vajrasky Kok wrote: Dear friends, from itertools import repeat list(repeat('a', 3)) ['a', 'a', 'a'] list(repeat('a', 0)) [] repeat.__doc__ 'repeat(object [,times]) -> create an iterator which returns the object\nfor the specified number of times. If not specified, re

Re: [Python-Dev] PEP 461 updates

Surprisingly, in this case the exception is just what the doctor ordered. :-) On Wed, Jan 15, 2014 at 6:12 PM, Glenn Linderman wrote: > On 1/15/2014 4:13 PM, Ethan Furman wrote: > > - no value generated errors > > ... > > > %c will insert a single byte, either from an int in range(256), or from

[Python-Dev] Signature of function with default value uncapturable in Python and C

Dear friends, >>> from itertools import repeat >>> list(repeat('a', 3)) ['a', 'a', 'a'] >>> list(repeat('a', 0)) [] >>> repeat.__doc__ 'repeat(object [,times]) -> create an iterator which returns the object\nfor the specified number of times. If not specified, returns the object\nendlessly.' If

Re: [Python-Dev] PEP 461 updates

On 1/15/2014 4:13 PM, Ethan Furman wrote: - no value generated errors ... %c will insert a single byte, either from an int in range(256), or from a bytes argument of length 1. what does x = 354 b"%c" % x produce? Seems that construct produces a value dependent error in both python 2 &

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

On Wed, Jan 15, 2014 at 05:46:07PM -0800, Glenn Linderman wrote: > On 1/15/2014 4:03 PM, Steven D'Aprano wrote: > >What precisely does it do? If it's so obvious, why is this thread so > >long? > > It produces a formatted representation of the object in bytes. For > numbers, that would probably b

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

On 1/15/2014 4:03 PM, Steven D'Aprano wrote: What precisely does it do? If it's so obvious, why is this thread so long? It produces a formatted representation of the object in bytes. For numbers, that would probably be expected to be ASCII digits and punctuation. But other items are not as

Re: [Python-Dev] PEP 461 updates

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: > > Abstract > > > This PEP proposes adding the % a

Re: [Python-Dev] PEP 460 reboot

On 15 Jan 2014 20:58, "Stephen J. Turnbull" wrote: > > Aside: OK, Guido, ya got me. > > I have a separate screed recounting the reasons for my apostasy, but > that's probably not interesting any more. I'll send it to individuals > on request. > > > But in terms of explaining the text model, that

[Python-Dev] PEP 461 updates

Current copy of PEP, many modifications from all the feedback. Thank you to everyone. I know it's been a long week (feels a lot longer!) while all this was hammered out, but I think we're getting close! Abstract This PEP proposes adding the % and {} form

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

On Wed, Jan 15, 2014 at 10:34:48PM +, Mark Lawrence wrote: > On 15/01/2014 22:22, Brett Cannon wrote: > > > > > > > >On Wed, Jan 15, 2014 at 5:00 PM, Steven D'Aprano >> wrote: > > > >On Thu, Jan 16, 2014 at 10:55:31AM +1300, Greg Ewing wrote: > > > Neil Sche

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

On Wed, Jan 15, 2014 at 09:25:04AM -0500, Eric V. Smith wrote: > On 1/15/2014 8:21 AM, Chris Angelico wrote: > > On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" > > wrote: > >> I don't think that it is possible to write an interpreter that is fully > >> compatible for all it accepts. Would yo

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

On 15/01/2014 22:22, Brett Cannon wrote: On Wed, Jan 15, 2014 at 5:00 PM, Steven D'Aprano mailto:st...@pearwood.info>> wrote: On Thu, Jan 16, 2014 at 10:55:31AM +1300, Greg Ewing wrote: > Neil Schemenauer wrote: > >Objects that implement __str__ can also implement __bytes__ if t

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

On 01/15/2014 08:33 AM, Mark Lawrence wrote: For completeness I believe %r and %a should be included here as well. Good point. Done. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Un

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

On Wed, Jan 15, 2014 at 5:00 PM, Steven D'Aprano wrote: > On Thu, Jan 16, 2014 at 10:55:31AM +1300, 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 _

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

On Wed, Jan 15, 2014 at 4:24 PM, Ethan Furman wrote: > On 01/15/2014 06:45 AM, Brett Cannon wrote: > >> >> I also think that a 'b' conversion be added to bytes.format(). This >> doesn't have the same issue as %b if you make {} >> implicitly mean {!b} in Python 3.5 as {} will mean what is the most

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

On 1/15/2014 4:32 PM, Ethan Furman wrote: > A question for anyone that has extensive experience in both %-formatting > and .format-formatting: Would it be possible, at least for int and > float, to take whatever is in the specifier and convert to %? Example: > > "Weight: {wgt:-07f}".format(wgt

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

On Thu, Jan 16, 2014 at 10:55:31AM +1300, 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

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

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 its binary value. -- Greg _

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

On 01/15/2014 06:45 AM, Brett Cannon wrote: The PEP currently says:: format -- The format mini language will be used as-is, with the behaviors as listed for %-interpolation. That's too vague; % interpolation does not support other format operators in the same way as str.f

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

On 01/15/2014 06:45 AM, Brett Cannon wrote: I also think that a 'b' conversion be added to bytes.format(). This doesn't have the same issue as %b if you make {} implicitly mean {!b} in Python 3.5 as {} will mean what is the most accurate for bytes.format() in either version. It also allows for

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

Glenn Linderman wrote: > On 1/15/2014 7:52 AM, Eric V. Smith wrote: >> Either that, or we're back to encoding the result of __format__ and >> accepting that sometimes it might throw errors, depending on the values >> being passed into format(). That would take us back to Python 2 hell. Please no

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

On 1/15/2014 7:52 AM, Eric V. Smith wrote: So basically I think we'll have to hard-code the types that .format() will support, and never call __format__, or only call __format__ if we know that it's a exact type where we know that __format__ will return (strict ASCII). Either that, or we're back

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

All sounds good. A fleeting thought about constructors: you can always add alternative constructors as class methods (like datetime does). On Wed, Jan 15, 2014 at 10:09 AM, Neil Schemenauer wrote: > Antoine Pitrou wrote: >> On Wed, 15 Jan 2014 15:47:43 + (UTC) Neil S wrote: >>> >>> Objects

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

Antoine Pitrou wrote: > On Wed, 15 Jan 2014 15:47:43 + (UTC) Neil S wrote: >> >> Objects that implement __str__ can also implement __bytes__ if they >> can guarantee that ASCII characters are always returned, no matter >> what the *value* > > I think that's a slippery slope. __bytes__ should

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

On Wed, 15 Jan 2014, Antoine Pitrou wrote: On Wed, 15 Jan 2014 15:47:43 + (UTC) Neil Schemenauer wrote: Objects that implement __str__ can also implement __bytes__ if they can guarantee that ASCII characters are always returned, no matter what the *value* I think that's a slippery slope

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

On 01/15/2014 08:51 AM, Brett Cannon wrote: On Wed, Jan 15, 2014 at 10:57 AM, Ethan Furman wrote: Thanks for your comments. I've only barely touched format, so it's not an area of strength for me. :) Time to strengthen it if you are proposing a PEP that is going to affect it. =) I am. Y

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

On Wed, Jan 15, 2014 at 10:57 AM, Ethan Furman wrote: > On 01/15/2014 06:45 AM, Brett Cannon wrote: > >> bytes.format() below. I'll leave it to you to decide if they warrant >> using, leaving as an open question, or rejecting. >> > > Thanks for your comments. I've only barely touched format, so

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

On Wed, Jan 15, 2014 at 10:52 AM, Eric V. Smith wrote: > On 1/15/2014 9:45 AM, Brett Cannon wrote: > > > That's too vague; % interpolation does not support other format > > operators in the same way as str.format() does. % interpolation has > > specific code to support %d, etc. But str.format() g

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

On 14/01/2014 19:56, Ethan Furman wrote: Duh. Here's the text, as well. ;) %s, because it is the most general, has the most convoluted resolution: - input type is bytes? pass it straight through - input type is numeric? use its __xxx__ [1] [2] method and ascii-encode it (stri

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

On 01/15/2014 07:47 AM, Neil Schemenauer wrote: Thanks for writing the PEP. Thank you for your comments! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.pyth

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

On 01/15/2014 08:04 AM, Antoine Pitrou wrote: On Wed, 15 Jan 2014 15:47:43 + (UTC) Neil Schemenauer wrote: Objects that implement __str__ can also implement __bytes__ if they can guarantee that ASCII characters are always returned, no matter what the *value* I think that's a slippery slo

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

On 01/14/2014 02:41 PM, Mark Lawrence wrote: On 14/01/2014 19:55, Ethan Furman wrote: This PEP goes a but further than PEP 460 does, and hopefully spells things out in enough detail so there is no confusion as to what is meant. -- ~Ethan~ Out of plain old curiosity do we have to consider PEP

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

Neil Schemenauer wrote: > We should use duck-typing and that means a special method, I > think. We could introduce a new one but __bytes__ looks like it > can work. Otherwise, maybe __ascii__ is a good name. I poked around the Python 3 source. Using __bytes__ has some downsides, e.g. the follo

Re: [Python-Dev] Changing Clinic's output

15.01.14 17:37, Larry Hastings написав(ла): On 01/15/2014 01:59 AM, Serhiy Storchaka wrote: 15.01.14 00:47, Larry Hastings написав(ла): I also can not change the text, but twice I was a witness as others did. And I see that make this mistake very easily. I also didn't modify the generated tex

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

On Wed, 15 Jan 2014 15:47:43 + (UTC) Neil Schemenauer wrote: > > Objects that implement __str__ can also implement __bytes__ if they > can guarantee that ASCII characters are always returned, no matter > what the *value* I think that's a slippery slope. __bytes__ should mean that the object

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

On 01/15/2014 06:45 AM, Brett Cannon wrote: bytes.format() below. I'll leave it to you to decide if they warrant using, leaving as an open question, or rejecting. Thanks for your comments. I've only barely touched format, so it's not an area of strength for me. :) -- ~Ethan~ __

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

On 1/15/2014 9:45 AM, Brett Cannon wrote: > That's too vague; % interpolation does not support other format > operators in the same way as str.format() does. % interpolation has > specific code to support %d, etc. But str.format() gets supported for > {:d} not from special code but because e.g. fl

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

This looks pretty good to me. I don't think we should limit operands based on type, that's anti-Pythonic IMHO. We should use duck-typing and that means a special method, I think. We could introduce a new one but __bytes__ looks like it can work. Otherwise, maybe __ascii__ is a good name. Object

Re: [Python-Dev] Changing Clinic's output

On 01/15/2014 01:59 AM, Serhiy Storchaka wrote: 15.01.14 00:47, Larry Hastings написав(ла): I also can not change the text, but twice I was a witness as others did. And I see that make this mistake very easily. I also didn't modify the generated text, but twice I was a witness as others did.

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

15.01.14 16:34, Antoine Pitrou написав(ла): If you explicitly create a long the L will always be printed: long(0) 0L Hey! long is not in common subset of Python 2 and Python 3. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python

Re: [Python-Dev] Binding problem

On Wed, 15 Jan 2014 11:53:05 +1100, "Rob Ward" wrote: > I apologise if I have come to the wrong place here, but 12hrs > searching, plus experimenting, on the WWW for advice on it has not > yielded any successful advice to resolve the issue. This is indeed the wrong place. Your best bet for gett

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

bytes.format() below. I'll leave it to you to decide if they warrant using, leaving as an open question, or rejecting. On Tue, Jan 14, 2014 at 2:56 PM, Ethan Furman wrote: > Duh. Here's the text, as well. ;) > > > PEP: 461 > Title: Adding % and {} formatting to bytes > Version: $Revision$ > L

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

On Thu, Jan 16, 2014 at 1:25 AM, Eric V. Smith wrote: >> Easiest fix for that would be to have long.__repr__ omit the L tag. >> Then it'll do the same as it would in Py3. > > I think Martin's point is not this specific thing, but that such a > subset would be useless. Would you drop dict.items() b

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

On Wed, 15 Jan 2014 16:31:17 +0200 Serhiy Storchaka wrote: > 15.01.14 14:22, "Martin v. Löwis" написав(ла): > > I don't think that it is possible to write an interpreter that is fully > > compatible for all it accepts. Would you think that the program > > > > print(repr(2**80).endswith("L")) > > >

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

15.01.14 14:22, "Martin v. Löwis" написав(ла): I don't think that it is possible to write an interpreter that is fully compatible for all it accepts. Would you think that the program print(repr(2**80).endswith("L")) is in the subset that should be supported by both Python 2 and Python 3? Notic

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

On 1/15/2014 8:21 AM, Chris Angelico wrote: > On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" > wrote: >> I don't think that it is possible to write an interpreter that is fully >> compatible for all it accepts. Would you think that the program >> >> print(repr(2**80).endswith("L")) >> >> is

Re: [Python-Dev] Changing Clinic's output

Larry Hastings wrote: > https://bitbucket.org/larry/clinic-buffer-samples/src Thanks for doing this! +1 for the sidefile, -1 for the current approach, +-0 for the rest. Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org https://mail

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

On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" wrote: > I don't think that it is possible to write an interpreter that is fully > compatible for all it accepts. Would you think that the program > > print(repr(2**80).endswith("L")) > > is in the subset that should be supported by both Python 2

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

On Wed, 15 Jan 2014 13:22:44 +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 but NOT

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

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 but NOT necsesarily with all existing code in either. It is >>> designed as a

Re: [Python-Dev] PEP 460 reboot

Aside: OK, Guido, ya got me. I have a separate screed recounting the reasons for my apostasy, but that's probably not interesting any more. I'll send it to individuals on request. > But in terms of explaining the text model, that > separation is important enough that > > (1) We should

Re: [Python-Dev] PEP 460: allowing %d and %f and mojibake

Tres Seaver writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 01/15/2014 12:57 AM, Stephen J. Turnbull wrote: > > > asciistr *canonizes* something as an ASCII string, and therefore > > compatible with both bytes and str. It can't *create* such a thing > > ex nihilo. >

Re: [Python-Dev] Changing Clinic's output

15.01.14 00:24, Larry Hastings написав(ла): But there's one important caveat to the above. As I recall, Guido has stated that he hates storing generated code in separate files. He has yet to rescind or weaken that pronouncement. Until such time as he does, the "side file" approach is off the ta

Re: [Python-Dev] Changing Clinic's output

15.01.14 00:47, Larry Hastings написав(ла): I also can not change the text, but twice I was a witness as others did. And I see that make this mistake very easily. I also didn't modify the generated text, but twice I was a witness as others did. And I see that make this mistake very easily.