Re: [Python-Dev] PEP 460 reboot

On 01/12/2014 10:51 PM, Nick Coghlan wrote: I am a strong -1 on the more lenient proposal, as it makes binary interpolation in Python 3 an *unsafe operation* for ASCII incompatible binary formats. No more unsafe that calling .upper() on ASCII incompatible streams. The existing binary operat

Re: [Python-Dev] PEP 460 reboot

On Sun, Jan 12, 2014 at 10:59 PM, Nick Coghlan wrote: > On 13 January 2014 16:52, Donald Stufft wrote: >> >> On Jan 13, 2014, at 12:45 AM, Glenn Linderman wrote: >> >> So then the question is whether to proceed with 3.4, delay this feature to >> 3.5, or to delay 3.4 to include this feature, both

Re: [Python-Dev] PEP 460 reboot

On Jan 13, 2014, at 1:59 AM, Nick Coghlan wrote: > On 13 January 2014 16:52, Donald Stufft wrote: >> >> On Jan 13, 2014, at 12:45 AM, Glenn Linderman wrote: >> >> So then the question is whether to proceed with 3.4, delay this feature to >> 3.5, or to delay 3.4 to include this feature, both

Re: [Python-Dev] PEP 460 reboot

On 13 January 2014 16:52, Donald Stufft wrote: > > On Jan 13, 2014, at 12:45 AM, Glenn Linderman wrote: > > So then the question is whether to proceed with 3.4, delay this feature to > 3.5, or to delay 3.4 to include this feature, both have been discussed, with > the justification for the latter

Re: [Python-Dev] PEP 460 reboot

On Jan 13, 2014, at 12:45 AM, Glenn Linderman wrote: > So then the question is whether to proceed with 3.4, delay this feature to > 3.5, or to delay 3.4 to include this feature, both have been discussed, with > the justification for the latter being to make 3.4 the ultimate Python 3 > porting

Re: [Python-Dev] PEP 460 reboot

On 13 January 2014 09:55, Guido van Rossum wrote: > There's a lot of discussion about PEP 460 and I haven't read it all. > Maybe you all have already reached the same conclusion that I have. In > that case I apologize (but the PEP should be updated). Here's my > contribution: > > PEP 460 itself cu

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

On 1/12/2014 4:08 PM, Stephen J. Turnbull wrote: Glenn Linderman writes: > the proposals to embed binary in Unicode by abusing Latin-1 > encoding. Those aren't "proposals", they are currently feasible techniques in Python 3 for *some* use cases. The question is why infecting Python 3 with

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

On 1/12/2014 8:00 PM, Ethan Furman wrote: Okay, I've thought somewhat. Under the definition above would it be fair to say that Db3Table (a class in my dbf module) is a boundary type? It sits between the actual file and the program, and transforms bytes into actual Python types. Yes. Tha

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

On 01/12/2014 02:32 PM, Mark Lawrence wrote: I've just tried asciistr using your test code (having corrected the typo, it's assertIsInstance, not assertIsinstance :) and it looks like a very good starting point. Have you, or anyone else for that matter, actually tried asciistr out? Ah, than

Re: [Python-Dev] PEP 460 reboot

On 1/12/2014 6:11 PM, Guido van Rossum wrote: On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote: >On 01/12/2014 04:47 PM, Guido van Rossum wrote: >>%s seems the trickiest: I think with a bytes argument it should just >>insert those bytes (and the padding modifiers should work too), and >>for

Re: [Python-Dev] PEP 460 reboot

On 01/12/2014 06:11 PM, Guido van Rossum wrote: On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote: On 01/12/2014 04:47 PM, Guido van Rossum wrote: %s seems the trickiest: I think with a bytes argument it should just insert those bytes (and the padding modifiers should work too), and for othe

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

On 01/12/2014 08:27 PM, Stephen J. Turnbull wrote: Ethan Furman writes: On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote: I didn't trim enough to make my point clear. My apologies. But knowledge of ASCII isn't necessary to specify these methods; they can be defined in an encoding/decodin

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

On 01/12/2014 07:02 PM, Stephen J. Turnbull wrote: [snip most of very eloquent reply] Thank you, Stephen, for remaining calm despite my somewhat heated response. A few comments in-line. I now better understand your viewpoint about text always being unicode strings; I just happen to disagree.

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

Ethan Furman writes: > On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote: > > No, Nick's point is that there's no encoding needed there are all, > > just a bunch of methods that handle numbers in the range 0-255. You > > can rationalize the particular choice of numbers by referring to the >

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Steven D'Aprano writes: > Of course you're right, but I have understood the above as being a > sketch and not real code. (E.g. does "header" really mean the literal > string "header", or does it stand in for something which is a header?) > In real code, one would need to have some way of te

Re: [Python-Dev] PEP 460 reboot

On 01/12/2014 07:45 PM, Guido van Rossum wrote: On Sun, Jan 12, 2014 at 6:16 PM, Ethan Furman wrote: In reference to a byte stream, if you do: --> b'%s' % 'some text'.encode('cp1241') it's really just bytes into bytes. That's a confusing example -- it would be clearer to just show b'%s' %

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

Those still arguing on this thread might want to look at the thread "PEP 460 reboot". -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://m

Re: [Python-Dev] PEP 460 reboot

On Sun, Jan 12, 2014 at 6:24 PM, Ethan Furman wrote: > On 01/12/2014 06:16 PM, Ethan Furman wrote: >> >> >> If you do : >> >> --> b'%s' % 'some text' > > > Ignore what I previously said. With no encoding the result would be: > > b"'some text'" > > So an encoding should definitely be specified. Y

Re: [Python-Dev] PEP 460 reboot

On Sun, Jan 12, 2014 at 6:16 PM, Ethan Furman wrote: > In reference to a byte stream, if you do: > > --> b'%s' % 'some text'.encode('cp1241') > > it's really just bytes into bytes. That's a confusing example -- it would be clearer to just show b'%s' % b'some text' > If you do : > > --> b'%s' %

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

On 2014-01-11 22:09, Nick Coghlan wrote: > For Python 2 folks trying to grok where the "bright line" is in terms of > the Python 3 text model: if your proposal includes *any* kind of > implicit serialisation of non binary data to binary, it is going to be > rejected as an addition to the core bytes

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

Ethan Furman writes: > 1) Are you saying it's okay to be insulting when frustrated? I >also find this mega-thread frustrating, but I'm trying >very hard not to be insulting. OK, no. Understandable, yes. > 2) If you are going to use my name, please be certain of the facts >[1].

Re: [Python-Dev] Smuggling bytes into text (was Re: RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5)

On 01/12/2014 06:03 PM, Steven D'Aprano wrote: The above all sounds reasonable. But the following does not -- I think it shows some fundamental confusion on your part. My apologies. The '\xd1.' was a bytestring, I forgot to type the b. (I know, I know, I should've copied and pasted :( )

Re: [Python-Dev] PEP 460 reboot

On 01/12/2014 06:16 PM, Ethan Furman wrote: If you do : --> b'%s' % 'some text' Ignore what I previously said. With no encoding the result would be: b"'some text'" So an encoding should definitely be specified. -- ~Ethan~ ___ Python-Dev mailing

Re: [Python-Dev] PEP 460 reboot

On 01/12/2014 06:07 PM, Daniel Holth wrote: On Sun, Jan 12, 2014 at 8:27 PM, Ethan Furman wrote: On 01/12/2014 04:47 PM, Guido van Rossum wrote: %s seems the trickiest: I think with a bytes argument it should just insert those bytes (and the padding modifiers should work too), and for other

Re: [Python-Dev] PEP 460 reboot

On Sun, Jan 12, 2014 at 9:18 PM, Guido van Rossum wrote: > On Sun, Jan 12, 2014 at 6:07 PM, Daniel Holth wrote: >> Is there a formatting character that means "anything except a unicode >> string" to prevent accidentally interpolating a Unicode string into a >> bytes string without [a sane] encodi

Re: [Python-Dev] Smuggling bytes into text (was Re: RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5)

On Mon, Jan 13, 2014 at 01:03:15PM +1100, Steven D'Aprano wrote: > code speaks louder than words: http://www.pearwood.info/ethan_demo.py [...] Ethan refers to code like: template % ("срЃ".encode('cp1251').decode('latin-1'), 42, blob.decode('latin-1')) > > You did say to use a *text* template

Re: [Python-Dev] PEP 460 reboot

On Sun, Jan 12, 2014 at 6:07 PM, Daniel Holth wrote: > Is there a formatting character that means "anything except a unicode > string" to prevent accidentally interpolating a Unicode string into a > bytes string without [a sane] encoding? No, and we shouldn't introduce one. An operation should ei

Re: [Python-Dev] PEP 460 reboot

On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote: > On 01/12/2014 04:47 PM, Guido van Rossum wrote: >> %s seems the trickiest: I think with a bytes argument it should just >> insert those bytes (and the padding modifiers should work too), and >> for other types it should probably work like %a,

Re: [Python-Dev] PEP 460 reboot

On Sun, Jan 12, 2014 at 8:27 PM, Ethan Furman wrote: > On 01/12/2014 04:47 PM, Guido van Rossum wrote: >> >> >> %s seems the trickiest: I think with a bytes argument it should just >> insert those bytes (and the padding modifiers should work too), and >> for other types it should probably work lik

[Python-Dev] Smuggling bytes into text (was Re: RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5)

Changing the subject line to better describe what we're talking about. I hope it is of interest to others apart from Ethan and I -- mixed bytes and text is hard to get right. (And if I've got something wrong, I'd like to know about it.) On Sat, Jan 11, 2014 at 08:38:49PM -0800, Ethan Furman wr

Re: [Python-Dev] PEP 460 reboot

On 01/12/2014 04:47 PM, Guido van Rossum wrote: %s seems the trickiest: I think with a bytes argument it should just insert those bytes (and the padding modifiers should work too), and for other types it should probably work like %a, so that it works as expected for numeric values, and with a st

Re: [Python-Dev] Trying to focus the whole bytes/str formatting discussion

Sorry, I started my own "PEP 460 reboot" thread -- I wrote that message before yours arrived, even if maybe I posted after you. I'm in the PBP camp myself for this. I won't pronounce on PEP 460 as-is. Please follow up in the other thread if you need clarifications. On Sun, Jan 12, 2014 at 2:46 PM,

Re: [Python-Dev] PEP 460 reboot

On 01/12/2014 03:55 PM, Guido van Rossum wrote: There's a lot of discussion about PEP 460 and I haven't read it all. Maybe you all have already reached the same conclusion that I have. No, no agreement has been reached. Your contribution is timely. PEP 460 itself currently rejects support f

Re: [Python-Dev] PEP 460 reboot

On Sun, Jan 12, 2014 at 4:28 PM, Ethan Furman wrote: > On 01/12/2014 03:55 PM, Guido van Rossum wrote: >> >> There's a lot of discussion about PEP 460 and I haven't read it all. >> Maybe you all have already reached the same conclusion that I have. > > > No, no agreement has been reached. Your co

Re: [Python-Dev] PEP 460 reboot

On Jan 12, 2014, at 6:55 PM, Guido van Rossum wrote: > The key reason for introducing a separate bytes type in Python 3 is to > avoid *mixing* bytes and text. This aims to avoid the classic Python 2 > Unicode failure, where str+unicode fails or succeeds based on whether > str contains non-ASCII

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 01/12/2014 04:02 PM, Stephen J. Turnbull wrote: So when you talk about "we", I suspect you are not the "we" everybody else is arguing with. In particular, AIUI your use case is not included in the use cases most of us -- including Steven -- are thinking about. Ah, so even in the minority I

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

Glenn Linderman writes: > the proposals to embed binary in Unicode by abusing Latin-1 > encoding. Those aren't "proposals", they are currently feasible techniques in Python 3 for *some* use cases. The question is why infecting Python 3 with the byte/character confoundance virus is preferable t

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Ethan Furman writes: > > This kind of subtlety is precisely why MAL warned about use of latin1 > > to smuggle bytes. > > And why I've been fighting Steven D'Aprano on it. No, I think you haven't been fighting Steven d'A on "it". You're talking about parsing and generating structured binary

[Python-Dev] PEP 460 reboot

There's a lot of discussion about PEP 460 and I haven't read it all. Maybe you all have already reached the same conclusion that I have. In that case I apologize (but the PEP should be updated). Here's my contribution: PEP 460 itself currently rejects support for %d, AFAIK on the basis that bytes

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

On 01/12/2014 02:52 PM, Antoine Pitrou wrote: You are right, it is not ok. The wording wasn't constructive or controlled at all. I'd like to apologize for that. Thank you. Apology accepted. At the same point, I was expressing a fair amount of frustration. I think the last discussion rounds

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

On 01/12/2014 02:57 PM, Stephen J. Turnbull wrote: Ethan Furman writes: Nothing else is ideal. I'll go that route if I have to. I understand that in the real world you go with what works, but in the development stage you fight for the ideal. :) You're going to lose, because Python 3 chose

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Mon, Jan 13, 2014 at 07:31:16AM +0900, Stephen J. Turnbull wrote: > Steven D'Aprano writes: > > > then the name is horribly misleading, and it is best handled like this: > > > > content = '\n'.join([ > > 'header', > > 'part 2 %.3f' % number, > > binary_image_d

Re: [Python-Dev] Trying to focus the whole bytes/str formatting discussion

On 12Jan2014 17:46, Brett Cannon wrote: > THE EIBTI group are willing to support PEP 460 but beyond that don't want > to have in Python itself anything for bytes.format() which takes in a > string and spits out bytes. It's bytes in->bytes out and not bytes & str > in->bytes out as the PBP group is

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

On 1/12/2014 2:57 PM, Stephen J. Turnbull wrote: > But bytes already acknowledges an ASCII bias. True, but that bias is implemented without use of encoding or decoding. b'%d' % (123,) -> b'123' does require encoding, at the very least in the sense of type change and serialization. b'%d' all

[Python-Dev] Python advanced debug support (update frame code)

Hi Python-dev. I'm playing a bit on the concept on live-coding during a debug session and one of the most annoying things is that although I can reload the code for a function (using something close to xreload), it seems it's not possible to change the code for the current frame (i.e.: I need to g

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

Ethan Furman writes: > Nothing else is ideal. I'll go that route if I have to. I > understand that in the real world you go with what works, but in > the development stage you fight for the ideal. :) You're going to lose, because Python 3 chose a different ideal that conflicts with yours.

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

Hi Ethan, On Sun, 12 Jan 2014 13:28:15 -0800 Ethan Furman wrote: > On 01/12/2014 12:02 PM, Stephen J. Turnbull wrote: > > Georg Brandl writes: > >> Antoine writes: > >>> > >>> . . . if it weren't for your stupid maximalist opposition. . . > >> > >> Can you please stop throwing personal insults a

[Python-Dev] Trying to focus the whole bytes/str formatting discussion

I don't know about the rest of you but I feel like the discussion is heading off the rails (if it hasn't already jumped the tracks). Let's try to bring this back around to something actionable which people can focus their energy on as the amount of developer time spent arguing could have led to sev

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 01/12/2014 02:31 PM, Stephen J. Turnbull wrote: This corrupts binary_image_data. Each byte > 127 will be replaced by two bytes. In the second case, you can use latin1 to encode, it it gives you what you want. This kind of subtlety is precisely why MAL warned about use of latin1 to smuggle

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

On 12/01/2014 17:03, Ethan Furman wrote: On 01/12/2014 08:21 AM, Ethan Furman wrote: On 01/12/2014 08:09 AM, Nick Coghlan wrote: On 13 Jan 2014 01:22, "Kristján Valur Jónsson" wrote: Imho, this is not equivalent to re-introducing automatic type conversion between binary/unicode, it is adding

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Steven D'Aprano writes: > then the name is horribly misleading, and it is best handled like this: > > content = '\n'.join([ > 'header', > 'part 2 %.3f' % number, > binary_image_data.decode('latin-1'), > utf16_string, # Misleading name, actually Unicode

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

On 12 January 2014 22:10, Greg Ewing wrote: > I think the readability argument becomes a bit sharper when > you consider more complex examples, e.g. if I have a tuple > of 3 floats that I want to put into a PDF file, then > >b"%f %f %f" % my_floats > > is considerably clearer than > >b" ".

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Mon, Jan 13, 2014 at 4:57 AM, Juraj Sukop wrote: > On Sun, Jan 12, 2014 at 6:22 PM, Steven D'Aprano > wrote: >> First, "utf16_string" confuses me. What is it? If it is a Unicode >> string, i.e.: > > It is a Unicode string which happens to contain code points outside U+00FF > (as with the TTF e

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 01/12/2014 01:59 PM, Mark Shannon wrote: Why not just use six.byte_format(fmt, *args)? It works on both Python2 and Python3 and accepts the numerical format specifiers, plus '%b' for inserting bytes and '%a' for converting text to ascii. Sounds like the second best option! Admittedly it

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

Mark Lawrence wrote: I entirely agree. This would also parallel the conversion flags given here http://docs.python.org/3/library/string.html#format-string-syntax, I quote "Three conversion flags are currently supported: '!s' which calls str() on the value, '!r' which calls repr() and '!a' whic

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

Ethan Furman wrote: Your asciistr, which sometimes returns bytes and sometimes returns text, is absolutely *not* what we want. The kind of third-party thing that *might* fill the bill would be a *function*: bytesformat(b"Content-Length: %d", length) that implements all the %-specifiers we'

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

Paul Moore wrote: On 12 January 2014 18:26, Ethan Furman wrote: I'm arguing from three PoVs: 1) 2 & 3 compatible code base 2) having the bytes type /be/ the boundary type 3) readable code The only one of these that I can see being in any way an argument against def int_to_bytes(n): retu

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

On 1/12/2014 11:14 AM, Ethan Furman wrote: And a core principle of the bytes/text separation in Python 3 is that encoding should never happen implicitly. That could be. And yet the bytes type already has several concessions to ASCII encoding. "%d" % 26 => an explicit request to convert bina

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

On 01/12/2014 01:37 PM, Kristján Valur Jónsson wrote: Right. I'm saying, let's support two interpolators only: %b interpolates a bytes object (or one supporting the charbuffer interface) into a bytes object. %s interpolates a str object by first converting to a bytes object using strict ascii c

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Why not just use six.byte_format(fmt, *args)? It works on both Python2 and Python3 and accepts the numerical format specifiers, plus '%b' for inserting bytes and '%a' for converting text to ascii. Admittedly it doesn't exist yet, but it could and it would save a lot of arguing :) (Apologies t

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

On 01/12/2014 01:06 PM, Greg Ewing wrote: Paul Moore wrote: I could easily argue at this point that this is the type of bug that having %-formatting operations on bytes would encourage - %s means "format a string" (from years of C and Python (text) experience) so I automatically supply a string

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

+1, even better. From: Python-Dev [python-dev-bounces+kristjan=ccpgames@python.org] on behalf of Mark Shannon [m...@hotpy.org] Sent: Sunday, January 12, 2014 17:06 To: python-dev@python.org Subject: Re: [Python-Dev] PEP 460: allowing %d and %f and moj

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

Right. I'm saying, let's support two interpolators only: %b interpolates a bytes object (or one supporting the charbuffer interface) into a bytes object. %s interpolates a str object by first converting to a bytes object using strict ascii conversion. This makes it very explicit what we are try

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On 01/12/2014 12:39 PM, Stephen J. Turnbull wrote: Daniel Holth writes: > -1 on adding more surrogateesapes by default. It's a pain to track > down where the encoding errors came from. What do you mean "by default"? It was quite explicit in the code I posted, and it's the only reasonable t

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

On 01/12/2014 12:02 PM, Stephen J. Turnbull wrote: Georg Brandl writes: Antoine writes: . . . if it weren't for your stupid maximalist opposition. . . Can you please stop throwing personal insults around? You don't have to resort to that level. Ethan's posts (as an example of one general

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

Nick Coghlan wrote: On 13 Jan 2014 01:22, "Kristján Valur Jónsson" > wrote: > Well, my suggestion would that we _should_ make it work, by having the %s format specifyer on bytes objects mean: str(arg).encode('ascii', 'strict') > It is not explicit, it is impli

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

On 12/01/2014 21:06, Greg Ewing wrote: Paul Moore wrote: I could easily argue at this point that this is the type of bug that having %-formatting operations on bytes would encourage - %s means "format a string" (from years of C and Python (text) experience) so I automatically supply a string arg

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

Paul Moore wrote: I could easily argue at this point that this is the type of bug that having %-formatting operations on bytes would encourage - %s means "format a string" (from years of C and Python (text) experience) so I automatically supply a string argument when using %s in a bytes formattin

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Daniel Holth writes: > -1 on adding more surrogateesapes by default. It's a pain to track > down where the encoding errors came from. What do you mean "by default"? It was quite explicit in the code I posted, and it's the only reasonable thing to do with "text data without known (but ASCII com

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

Am 12.01.2014 20:30, schrieb Emile van Sebille: > On 01/12/2014 09:26 AM, Paul Moore wrote: >> Can you give an example of code that is *nearly* acceptable to you, >> which works in Python 2 and 3 today, and explain what improvements you >> would like to see to it in order to use it instead of waiti

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

Georg Brandl writes: > > if it weren't for your stupid maximalist opposition). > > Can you please stop throwing personal insults around? You don't have to > resort to that level. Ethan's posts (as an example of one general trend in this thread) are pretty frustrating, you have to admit. MA

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

On 01/12/2014 11:30 AM, Emile van Sebille wrote: On 01/12/2014 09:26 AM, Paul Moore wrote: Can you give an example of code that is *nearly* acceptable to you, which works in Python 2 and 3 today, and explain what improvements you would like to see to it in order to use it instead of waiting for

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

On 12 January 2014 19:30, Emile van Sebille wrote: > len(open('chars','wb').write("".join(map (chr,range(256.read()) Python 2: >>> len(open('chars','wb').write("".join(map (chr,range(256.read()) Traceback (most recent call last): File "", line 1, in AttributeError: 'NoneType' object h

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

On 01/12/2014 11:00 AM, Paul Moore wrote: And yet I still don't follow what you *want*. Unless it's that b'%d' % (12,) must work and give b'12', and nothing else is acceptable. Nothing else is ideal. I'll go that route if I have to. I understand that in the real world you go with what works,

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

On 01/12/2014 09:26 AM, Paul Moore wrote: Can you give an example of code that is *nearly* acceptable to you, which works in Python 2 and 3 today, and explain what improvements you would like to see to it in order to use it instead of waiting for a core change? I'm not a developer, but I'm try

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

On 01/11/2014 07:09 PM, Nick Coghlan wrote: Folks that want implicit serialisation (and I agree it has its uses) should go help Benno get asciistr up to speed. asciistr is not what I'm looking for in the way of a boundary type. I have created a 'bytestring'[1] repository which has the tests

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

I want to add one more PoV: small performance regression, especially on Python 2. Because programs that needs byte formatting may be low level and used heavily from application. Many programs uses one source approach to support Python 3. And supporting Python 3 should not means large performance r

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

On 12 January 2014 18:26, Ethan Furman wrote: > True enough! ;) It's unacceptable in the sense that the bytes type is > /almost/ there, it's /almost/ what is needed to handle the boundary > conditions. We have a __bytes__ method (how is it supposed to be used?) > that could be made to fit the i

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

On 01/12/2014 09:26 AM, Paul Moore wrote: On 12 January 2014 17:03, Ethan Furman wrote: We know full well the difference between unicode and bytes, and we know full well that numbers and much of the text we need has an ASCII (bytes!) representation. When we do a b'Content Length: %d' % len(bin

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

Wait a second, this is how I understood it but what Nick said made me think otherwise... On Sun, Jan 12, 2014 at 6:22 PM, Steven D'Aprano wrote: > On Sun, Jan 12, 2014 at 12:52:18PM +0100, Juraj Sukop wrote: > > On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano >wrote: > > > > Just to check I und

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

On Sun, Jan 12, 2014 at 3:58 PM, Nick Coghlan wrote: > > On 12 Jan 2014 23:39, "Nachshon David Armon" > wrote: >> >> 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 necs

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Sun, Jan 12, 2014 at 11:16:37PM +1000, Nick Coghlan wrote: > > content = '\n'.join([ > > 'header', > > 'part 2 %.3f' % number, > > binary_image_data.decode('latin-1'), > > utf16_string.encode('utf-16be').decode('latin-1'), > > 'trailer']).encode('lati

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

On 12 January 2014 17:03, Ethan Furman wrote: > We know full well the difference between unicode and bytes, and we know full > well that numbers and much of the text we need has an ASCII (bytes!) > representation. When we do a b'Content Length: %d' % len(binary_data) we > are expecting to get bac

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

On 12/01/2014 17:06, Mark Shannon wrote: On 12/01/14 16:52, Kristján Valur Jónsson wrote: Now you're just splitting hairs, Nick. An explicit operator, %s, _defined_ to be "encode a string object using strict ascii", I don't like this because '%s' reads to me as "insert *string* here". I think

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Sun, Jan 12, 2014 at 12:52:18PM +0100, Juraj Sukop wrote: > On Sun, Jan 12, 2014 at 2:35 AM, Steven D'Aprano wrote: > > > On Sat, Jan 11, 2014 at 08:13:39PM -0200, Mariano Reingart wrote: > > > > > AFAIK (and just for the record), there could be both Latin1 text and > > UTF-16 > > > in a PDF (a

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

On 12/01/14 16:52, Kristján Valur Jónsson wrote: Now you're just splitting hairs, Nick. An explicit operator, %s, _defined_ to be "encode a string object using strict ascii", I don't like this because '%s' reads to me as "insert *string* here". I think '%a' which reads as "encode as ASCII and

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

On 12 January 2014 16:52, Kristján Valur Jónsson wrote: > I mean, basically what I am suggesting is that in addition to %b with > > def helper(o): > return str(o).encode('ascii', 'strict') > > b'foo%bbar'%(helper(myobj), ) > > you have > > b'foo%sbar'%(myobj, ) But that's not what the current

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

On 01/12/2014 08:21 AM, Ethan Furman wrote: On 01/12/2014 08:09 AM, Nick Coghlan wrote: On 13 Jan 2014 01:22, "Kristján Valur Jónsson" wrote: Imho, this is not equivalent to re-introducing automatic type conversion between binary/unicode, it is adding a specific convenience function for expli

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

Now you're just splitting hairs, Nick. An explicit operator, %s, _defined_ to be "encode a string object using strict ascii", how is that any less explicit than the .encode('ascii', 'strict') spelt out in full? The language is full of constructs that are shorthands for others, more lengthy bu

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

On 01/12/2014 08:09 AM, Nick Coghlan wrote: On 13 Jan 2014 01:22, "Kristján Valur Jónsson" wrote: Imho, this is not equivalent to re-introducing automatic type conversion between binary/unicode, it is adding a specific convenience function for explicitly asking for ASCII encoding. It is not

Re: [Python-Dev] test.support.check_warnings

On 01/12/2014 04:24 AM, Antoine Pitrou wrote: On Sat, 11 Jan 2014 23:10:43 -0800 Ethan Furman wrote: On 01/11/2014 05:37 PM, Brett Cannon wrote: You're assuming the context manager is doing something magical to verify that all calls in the block raise the expected exception. What you want to

Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5

On Sun, Jan 12, 2014 at 2:16 PM, Nick Coghlan wrote: > Why are you proposing to do the *join* in text space? Encode all the parts > separately, concatenate them with b'\n'.join() (or whatever separator is > appropriate). It's only the *text formatting operation* that needs to be > done in text sp

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

On 13 Jan 2014 01:22, "Kristján Valur Jónsson" wrote: > > > Well, my suggestion would that we _should_ make it work, by having the %s format specifyer on bytes objects mean: str(arg).encode('ascii', 'strict') > It would be an explicit encoding operator with a known, fixed, and well specified encod

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

On Sat, Jan 11, 2014 at 8:40 PM, Kristján Valur Jónsson wrote: > Hi there. > How about a compromise? > Personally, I think adding the full complement of integer/float formatting to > bytes is a bit over the top. > How about just supporting two format specifiers? > %b : interpolate a bytes object.

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

Well, my suggestion would that we _should_ make it work, by having the %s format specifyer on bytes objects mean: str(arg).encode('ascii', 'strict') It would be an explicit encoding operator with a known, fixed, and well specified encoder. This would cover most of the use cases seen in this thre

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #19092 - Raise a correct exception when cgi.FieldStorage is given an

On Sat, Jan 11, 2014 at 11:53 PM, Nick Coghlan wrote: > You may want to tweak the tracker so the comment ends up on the > appropriate issue (#19092 is something else entirely) > Yes. This was supposed to be #19097. My bad. ___ Python-Dev mailing list

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

On 12 Jan 2014 23:39, "Nachshon David Armon" wrote: > > Hi, > I am Nachshon and this is my first post to the python mailing list. > > I have been porting some libraries from python 2 to python 3 recently with the goal of a common codebase that will run on both versions. I was thinking it would mak

Re: [Python-Dev] cpython (3.3): Update Sphinx toolchain.

That's also planned, see https://bitbucket.org/birkenfeld/sphinx-new-make-mode/. Georg Am 12.01.2014 09:49, schrieb anatoly techtonik: > And cross-platform automation tools in Python instead of make > https://bitbucket.org/birkenfeld/sphinx/issue/456/makepy-command-script > -- > anatoly t. > >

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

Hi Nachson, Python 2.7 with the -3 warning flag covers most of this, while using tox to run automated tests under both 2.x and 3.x should cover the rest (tox is also useful for checking code runs under Python 2.6, even if you normally use a newer version). Is there anything in particular you feel

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

Hi, I am Nachshon and this is my first post to the python mailing list. I have been porting some libraries from python 2 to python 3 recently with the goal of a common codebase that will run on both versions. I was thinking it would make my life, and a lot of other developers as well, a lot easier

  1   2   >