Re: [Python-Dev] PEP 461 Final?

Steven D'Aprano, 18.01.2014 02:27: > On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote: >> %s is restricted in what it will accept:: >> >> - input type supports Py_buffer? >> use it to collect the necessary bytes > > Can you give some examples of what types support Py_buffer? Pres

Re: [Python-Dev] PEP 461 Final?

Nick Coghlan writes: > I also suggest introducing the phrase "ASCII compatible > segments in binary formats" somewhere, What is the use case for "ASCII *compatible* segments"? Can't you just say "ASCII segments"? I'm not sure exactly what PEP 461 says at this point, but most of the discussion

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

Neil Schemenauer writes: > I'd like to try porting code making use of the -2 feature to see how > helpful it is. The behavior is partway between Python 2.x laziness > and Python 3.x strictness in terms of specifying encodings. > > Python 2.x: > [...] > Python 3.x: > [...] The above are

Re: [Python-Dev] PEP 461 Final?

+1 on the technical spec from me. The rationale needs work, but you already know that :) For API consistency, I suggest explicitly noting that bytearray will also support the operation, generating a bytearray result. I also suggest introducing the phrase "ASCII compatible segments in binary forma

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

On 18 Jan 2014 06:19, "Terry Reedy" wrote: > > On 1/17/2014 10:15 AM, Mark Lawrence wrote: > >> For both options 1 and 2 surely you cannot be suggesting that after >> people have written 2.x code to use format() as %f formatting is to be >> deprecated, > > > I will not be for at least a decade. I

Re: [Python-Dev] PEP 461 Final?

On 01/17/2014 06:03 PM, Chris Angelico wrote: On Sat, Jan 18, 2014 at 12:51 PM, Ethan Furman wrote: It seems there are two possibilities with %a: 1) have it be ascii(repr(obj)) Wouldn't that be redundant? ascii() is already repr()-like. Good point. -- ~Ethan~ __

Re: [Python-Dev] PEP 461 Final?

On Sat, Jan 18, 2014 at 12:51 PM, Ethan Furman wrote: > It seems there are two possibilities with %a: > > 1) have it be ascii(repr(obj)) Wouldn't that be redundant? ascii() is already repr()-like. ChrisA ___ Python-Dev mailing list Python-Dev@python.

Re: [Python-Dev] PEP 461 Final?

On 01/17/2014 05:27 PM, Steven D'Aprano wrote: On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote: Overriding Principles = In order to avoid the problems of auto-conversion and Unicode exceptions that could plague Py2 code, all object checking will be done by duck

Re: [Python-Dev] PEP 461 Final?

On Fri, Jan 17, 2014 at 08:49:21AM -0800, Ethan Furman wrote: > Overriding Principles > = > > In order to avoid the problems of auto-conversion and Unicode exceptions > that > could plague Py2 code, all object checking will be done by duck-typing, not > by > values contained

Re: [Python-Dev] PEP 461 updates

On 1/17/2014 4:37 PM, Chris Barker wrote: > For the record, we've got a pretty good thread (not this good, though!) > over on the numpy list about how to untangle the mess that has resulted > from porting text-file-parsing code to py3 (and the underlying issue > with the 'S' data type in numpy...)

Re: [Python-Dev] PEP 461 updates

I hope you didn't mean to take this off-list: On Fri, Jan 17, 2014 at 2:06 PM, Neil Schemenauer wrote: > In gmane.comp.python.devel, you wrote: > > For the record, we've got a pretty good thread (not this good, though!) > > over on the numpy list about how to untangle the mess that has resulted >

Re: [Python-Dev] PEP 461 updates

For the record, we've got a pretty good thread (not this good, though!) over on the numpy list about how to untangle the mess that has resulted from porting text-file-parsing code to py3 (and the underlying issue with the 'S' data type in numpy...) One note from the github issue: """ The use of a

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

Responding to two posts at once, as I consider them On 1/17/2014 11:00 AM, Brett Cannon wrote: I would rephrase it to "switch to %-formatting for bytes usage for their common code base". If they are working with actual text then using str.format() still works (and is actually nicer to use IMO).

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

Regardless, I still feel the introduction of a switch and all that stuff is too complicated. I understand you position, since all my applications are written in Python 2(except 1). However, I don't think this is the best solution. On Fri, Jan 17, 2014 at 2:19 PM, Neil Schemenauer wrote: > On 20

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

Glenn Linderman wrote: > -1 overall. > > Not worth the extra complexity in documentation and command line > parameters. Really? It's less than 20 lines of code to implement, probably similar to document. With millions maybe billions of lines of existing Python 2.x code to port, I'm dismayed to

Re: [Python-Dev] PEP 461 Final?

On 01/17/2014 08:53 AM, Brett Cannon wrote: Don't abbreviate; spell out "Python 2". Fixed. Originally this PEP also proposed adding format style formatting, but it was "format-style" Fixed. decided that format and its related machinery were all strictly text (aka str) ba

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

On 2014-01-17, Ryan Gonzalez wrote: > A command line parameter?? I believe it has to be global flag. A __future__ statement will not work. Probably we should allow the flag to be set with an environment variable as well. > The annoying part would be telling every single user to call Python with

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

On 1/17/2014 10:15 AM, Mark Lawrence wrote: For both options 1 and 2 surely you cannot be suggesting that after people have written 2.x code to use format() as %f formatting is to be deprecated, I will not be for at least a decade. they now have to change the code back to the way they may we

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

A command line parameter?? The annoying part would be telling every single user to call Python with a certain argument and hope they read the README. If it's a library, out of the question. If it's a program, well, I hope your users read READMEs. On Fri, Jan 17, 2014 at 4:49 AM, Neil Schemenau

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

I've refined this idea a little in my latest PEP 461 patch (issue 20284). Continuing to use %s instead of introducing %b seems better. I've called the commmand-line option -2, it could be used to enable other similar porting aids. I'd like to try porting code making use of the -2 feature to see

Re: [Python-Dev] Migration from Python 2.7 and bytes formatting

On 1/17/2014 2:49 AM, Neil Schemenauer wrote: As I see it, there are two separate goals in adding formatting methods to bytes. One is to make it easier to write new programs that manipulate byte data. Another is to make it easier to upgrade Python 2.x programs to Python 3.x. Here is an idea to

Re: [Python-Dev] PEP 461 Final?

Mark Lawrence wrote: > Using %b could cause problems in the future as b is used in new style > formatting to mean output numbers in binary, so %B seems to me the > obvious choice as it's also unused. After updating my patch, I've decided that %s works better. My patch implements PEP 461 as pro

Re: [Python-Dev] PEP 461 Final?

On 01/17/2014 11:40 AM, Glenn Linderman wrote: On 1/17/2014 8:49 AM, Ethan Furman wrote: >>> b'%s' % 3.14 Traceback (most recent call last): ... TypeError: 3.14 has no __bytes__ method If you produce a helpful error message for str (re: encoding), might it not be appropriate

Re: [Python-Dev] PEP 461 Final?

On 1/17/2014 8:49 AM, Ethan Furman wrote: %s is restricted in what it will accept:: - input type supports Py_buffer? use it to collect the necessary bytes - input type is something else? use its __bytes__ method; if there isn't one, raise a TypeError Examples: >>> b'%s' % b'ab

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

On 01/17/2014 02:04 PM, Glenn Linderman wrote: > On 1/17/2014 7:15 AM, Mark Lawrence wrote: >> For both options 1 and 2 surely you cannot be suggesting that after >> people have written 2.x code to use format() as %f formatting is to be >> deprecated, they now have to change the code back to the wa

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

On 1/17/2014 7:15 AM, Mark Lawrence wrote: For both options 1 and 2 surely you cannot be suggesting that after people have written 2.x code to use format() as %f formatting is to be deprecated, they now have to change the code back to the way they may well have written it in the first place?

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

On 1/17/2014 6:50 AM, Eric V. Smith wrote: Following up, I think this leaves us with 3 choices: 1. Do not implement bytes.format(). We tell any 2.x code that's written to use str.format() to switch to %-formatting for their common code base. 2. Add the simplistic version of bytes.format() that

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

On 01/17/2014 09:13 AM, Eric V. Smith wrote: On 01/17/2014 11:58 AM, Brett Cannon wrote: On Fri, Jan 17, 2014 at 11:16 AM, Barry Warsaw wrote: On Jan 17, 2014, at 11:00 AM, Brett Cannon wrote: I would rephrase it to "switch to %-formatting for bytes usage for their common code base". -1. %

Re: [Python-Dev] PEP 461 Final?

On 01/17/2014 09:46 AM, Neil Schemenauer wrote: Rational "Rationale". "Rational" is an adjective, "Rationale" is a noun. Pedantically yours, //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mail

Re: [Python-Dev] PEP 461 Final?

On 17/01/2014 17:46, Neil Schemenauer wrote: I think we should use %b instead of %s. In that case, I'm fine with %b not accepting numbers. Using %b clearly indicates we are inserting arbitrary bytes. It also proves a useful code review step when translating from Python 2.x. Using %b could

Re: [Python-Dev] PEP 461 Final?

Ethan Furman wrote: > Overriding Principles >= > > In order to avoid the problems of auto-conversion and Unicode exceptions that > could plague Py2 code, all object checking will be done by duck-typing, not by > values contained in a Unicode representation [3]_. I think a long

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

On 01/17/2014 11:58 AM, Brett Cannon wrote: > > > > On Fri, Jan 17, 2014 at 11:16 AM, Barry Warsaw > wrote: > > On Jan 17, 2014, at 11:00 AM, Brett Cannon wrote: > > >I would rephrase it to "switch to %-formatting for bytes usage for > their > >common

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2014-01-10 - 2014-01-17) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4437 (+28) closed 27624 (+44) total 32061 (+72) Open issues wit

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

On Fri, Jan 17, 2014 at 11:16 AM, Barry Warsaw wrote: > On Jan 17, 2014, at 11:00 AM, Brett Cannon wrote: > > >I would rephrase it to "switch to %-formatting for bytes usage for their > >common code base". > > -1. %-formatting is so neanderthal. :) > Very much so, which is why I'm willing to le

Re: [Python-Dev] PEP 461 Final?

On Fri, Jan 17, 2014 at 11:49 AM, Ethan Furman wrote: > Here's the text for your reading pleasure. I'll commit the PEP after I > add some markup. > > Major change: > > - dropped `format` support, just using %-interpolation > > Coming soon: > > - Rationale section ;) > >

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

On 01/16/2014 11:47 PM, Steven D'Aprano wrote: 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

[Python-Dev] PEP 461 Final?

Here's the text for your reading pleasure. I'll commit the PEP after I add some markup. Major change: - dropped `format` support, just using %-interpolation Coming soon: - Rationale section ;) PEP: 461 Tit

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

On 18 Jan 2014 02:08, "Paul Moore" wrote: > > On 17 January 2014 15:50, Eric V. Smith wrote: > > For #3, hopefully this "additional work" on the 3.x side would just be > > to add, to each class where you already have a custom __format__ used > > for b''.format(), code like: > > > > def __form

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

On Jan 17, 2014, at 11:00 AM, Brett Cannon wrote: >I would rephrase it to "switch to %-formatting for bytes usage for their >common code base". -1. %-formatting is so neanderthal. :) -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mai

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

On 17 January 2014 15:50, Eric V. Smith wrote: > For #3, hopefully this "additional work" on the 3.x side would just be > to add, to each class where you already have a custom __format__ used > for b''.format(), code like: > > def __format_ascii__(self, fmt): > return self.__format__(f

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

On Fri, Jan 17, 2014 at 9:50 AM, Eric V. Smith wrote: > On 01/17/2014 07:34 AM, Eric V. Smith wrote: > > On 1/17/2014 6:42 AM, Nick Coghlan wrote: > >> > >> On 17 Jan 2014 18:03, "Eric Snow" >> > wrote: > >>> > >>> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smi

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

On 17/01/2014 15:41, Ethan Furman wrote: On 01/17/2014 07:15 AM, Mark Lawrence wrote: For both options 1 and 2 surely you cannot be suggesting that after people have written 2.x code to use format() as %f formatting is to be deprecated %f formatting is not deprecated, and will not be in 3.x'

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

On 01/17/2014 10:24 AM, Eric V. Smith wrote: > On 01/17/2014 10:15 AM, Mark Lawrence wrote: >> On 17/01/2014 14:50, Eric V. Smith wrote: >>> On 01/17/2014 07:34 AM, Eric V. Smith wrote: On 1/17/2014 6:42 AM, Nick Coghlan wrote: > > On 17 Jan 2014 18:03, "Eric Snow"

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

On 01/17/2014 07:15 AM, Mark Lawrence wrote: For both options 1 and 2 surely you cannot be suggesting that after people have written 2.x code to use format() as %f formatting is to be deprecated %f formatting is not deprecated, and will not be in 3.x's lifetime. -- ~Ethan~ __

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

On 01/17/2014 10:15 AM, Mark Lawrence wrote: > On 17/01/2014 14:50, Eric V. Smith wrote: >> On 01/17/2014 07:34 AM, Eric V. Smith wrote: >>> On 1/17/2014 6:42 AM, Nick Coghlan wrote: On 17 Jan 2014 18:03, "Eric Snow" >>> > wrote: > > On Thu, Jan

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

On 17/01/2014 14:50, Eric V. Smith wrote: On 01/17/2014 07:34 AM, Eric V. Smith wrote: On 1/17/2014 6:42 AM, Nick Coghlan wrote: On 17 Jan 2014 18:03, "Eric Snow" mailto:ericsnowcurren...@gmail.com>> wrote: On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith > wrote:

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

On 01/17/2014 07:34 AM, Eric V. Smith wrote: > On 1/17/2014 6:42 AM, Nick Coghlan wrote: >> >> On 17 Jan 2014 18:03, "Eric Snow" > > wrote: >>> >>> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith > > wrote: For the first iteration

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

On 1/17/2014 6:42 AM, Nick Coghlan wrote: > > On 17 Jan 2014 18:03, "Eric Snow" > wrote: >> >> On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith > wrote: >> > For the first iteration of bytes.format(), I think we should just >> > suppo

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

On 17 Jan 2014 18:03, "Eric Snow" wrote: > > On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith wrote: > > For the first iteration of bytes.format(), I think we should just > > support the exact types of int, float, and bytes. It will call the > > type's__format__ (with the object as "self") and enc

[Python-Dev] Migration from Python 2.7 and bytes formatting

As I see it, there are two separate goals in adding formatting methods to bytes. One is to make it easier to write new programs that manipulate byte data. Another is to make it easier to upgrade Python 2.x programs to Python 3.x. Here is an idea to better address these separate goals. Introduce

Re: [Python-Dev] PEP 461 updates

Steven D'Aprano writes: > On Fri, Jan 17, 2014 at 11:19:44AM +0900, Stephen J. Turnbull wrote: > > "ASCII compatible" is a technical term in encodings, which means > > "bytes in the range 0-127 always have ASCII coded character semantics, > > do what you like with bytes in the range 128-255."[

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

On Thu, Jan 16, 2014 at 01:08:47PM -0800, Ryan Smith-Roberts wrote: > socket.getservbyname(servicename[, protocolname]) > > This is not an inspectable signature, since pure Python does not support > bracketed arguments. To make it inspectable, we must give protocolname a > (valid Python) default

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

On Thu, Jan 16, 2014 at 3:06 PM, Jan Kaliszewski wrote: > I'd treat the format()+.__format__()+str.format()-"ecosystem" as > a nice text-data-oriented, *complete* Py3k feature, backported to > Python 2 to share the benefits of the feature with it as well as > to make the 2-to-3 transition a bit ea

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

On Thu, Jan 16, 2014 at 11:30 AM, Eric V. Smith wrote: > For the first iteration of bytes.format(), I think we should just > support the exact types of int, float, and bytes. It will call the > type's__format__ (with the object as "self") and encode the result to > ASCII. For the stated use case o