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

On 01/14/2014 08:31 PM, Larry Hastings wrote: I've added a fourth feature to the prototype: set line_prefix lets you set a string that is prepended to every line of code generated by Clinic. Without the coloring support of my editor I would find that very useful indeed. But since I ha

Re: [Python-Dev] PEP 460 reboot

> Right, that's the danger I was worried about, but the problem is that > there's at least *some* minimum level of ASCII compatibility that > needs to be assumed in order to define an interpolation format at all > (this is the point I originally missed). Only if you insist that bytes formats

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

-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. How many miracles must be attested? Tres. - -

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

Steven D'Aprano writes: > I thought I understand the purpose of asciistr was exactly that, to > produce something that was compatible with both bytes and strings. asciistr *canonizes* something as an ASCII string, and therefore compatible with both bytes and str. It can't *create* such a thing

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

On Tue, Jan 14, 2014 at 3:12 PM, Antoine Pitrou wrote: On Tue, 14 Jan 2014 12:22:12 -0800 > Larry Hastings wrote: > > > > https://bitbucket.org/larry/clinic-buffer-samples/src > > > > In it I converted Modules/_pickle.c four different ways. There's a > > README, please read it. > > I'm +1 o

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

On 01/14/2014 12:22 PM, Larry Hastings wrote: On 01/11/2014 07:35 PM, Larry Hastings wrote: I've uploaded a prototype here: https://bitbucket.org/larry/python-clinic-buffer [...] I've created a new repository containing the "concrete examples of the various options" that Barry proposed

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

Steven D'Aprano wrote: I don't think mixing bytes and strings makes good semantic sense. It's not about mixing bytes and text -- it's about writing polymorphic code that will work on either bytes *or* text. Not both at the same time. If we had quantum computers, this would be easy to solve: a

Re: [Python-Dev] PEP 460 reboot

I am exhausted from all these discussions. I just recommend not touching those docs. On Tue, Jan 14, 2014 at 8:08 PM, Jim Jewett wrote: > On Tue, Jan 14, 2014 at 3:06 PM, Guido van Rossum wrote: >> Personally I wouldn't add any words suggesting or referring to the >> option of creation another c

Re: [Python-Dev] magic method __bytes__

R. David Murray writes: > a file is a just a "wire" with an indefinite destination and > transmission time +1 QOTW Of course! "Store and ... wait for it ... forward" architecture 4-ever! Store and Forward, Inc. Since 1969. ___ Python-Dev mailing l

Re: [Python-Dev] PEP 460 reboot

On Tue, Jan 14, 2014 at 3:06 PM, Guido van Rossum wrote: > Personally I wouldn't add any words suggesting or referring to the > option of creation another class for this purpose. You wouldn't > recommend subclassing dict for constraining the types of keys or > values, would you? Yes, and it is so

Re: [Python-Dev] Binding problem

Hey Rob, The place to get help with Tkinter is tkinter-disc...@python.org. I've CC'ed that list for you. --Guido On Tue, Jan 14, 2014 at 4:53 PM, 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

Re: [Python-Dev] Binding problem

On 2014-01-15 00:53, 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. I am am having trouble binding an Entry widget to Here is the snippet (butC

Re: [Python-Dev] Binding problem

On 1/14/2014 7:53 PM, Rob Ward wrote: I apologise if I have come to the wrong place here, Yes, you have ;-). pydev is for development *of* future versions of Python. Try python-list for development *with* current version. -- Terry Jan Reedy ___ Py

Re: [Python-Dev] PEP 460 reboot

On 14Jan2014 11:43, Jim Jewett wrote: > Greg Ewing replied: > >> ... ASCII compatible binary data is a > >> *subset* of arbitrary binary data. > > I wrote: [...] > >(2) It *may* be worth creating a virtual > > split in the documentation. [...] > > Ethan likes the idea, but points ou

[Python-Dev] Binding problem

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. I am am having trouble binding an Entry widget to Here is the snippet (butCol is a Frame widget to put buttons,l

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

On 01/14/2014 05:32 PM, Ryan Smith-Roberts wrote: Pondering it this afternoon, I thought of a configuration that minimizes both code churn and readability impact: two buffers. One at the top containing forward declarations and defines (an inline header file if you like), and the rest of the au

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

On 01/14/2014 05:02 PM, Glenn Linderman wrote: On 1/14/2014 2:38 PM, Nick Coghlan wrote: I think Brett has the right idea: we shouldn't try to accept numbers for %s in binary interpolation. If we limit it to just buffer exporters and objects with a __bytes__ method then the problem goes away.

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

On Wed, Jan 15, 2014 at 01:03:13PM +1300, Greg Ewing wrote: > Nick Coghlan wrote: > >That way lies the Python 2 text model, and we're not going there. It's > >probably best to think of asciistr as a way of demonstrating a > >rhetorical point about the superiority of the Python 3 text model > >

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

On 01/14/2014 02:28 PM, Larry Hastings wrote: On 01/14/2014 12:51 PM, Ethan Furman wrote: I checked the README, the current file, and the buffered files. My preferences from highest to lowest: +1 modified buffer approach +0.5 buffer approach +0 side file NaN on the others is fine.

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

On Tue, Jan 14, 2014 at 5:32 PM, Ryan Smith-Roberts wrote: > NaN _pickle.using-sidefile.c /* not enough experience with it */ > I hate to weasel like that. Intellectually I think I favor the sidefile over all other approaches for its cleanliness. But I'd have to actively use it in a workflow a b

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

I favor a dual-mode approach. I think the existing behavior is best for the conversion of existing modules, because it's easy to interactively verify the generated code. Once that's done, long-term maintenance definitely favors a more centralized format. +1 _pickle.original.c /* used only during c

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

On Tue, Jan 14, 2014 at 10:16:17AM -0800, Guido van Rossum wrote: > Hm. It is beginning to sound more and more flawed. I also worry that > it will bring back the nightmare of data-dependent UnicodeError back. > E.g. this (from tests/basic.py): > > def test_asciistr_will_not_accept_codepoints_

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

On 1/14/2014 2:38 PM, Nick Coghlan wrote: I think Brett has the right idea: we shouldn't try to accept numbers for %s in binary interpolation. If we limit it to just buffer exporters and objects with a __bytes__ method then the problem goes away. The numeric codes all exist in Python 2, so t

Re: [Python-Dev] PEP 460 reboot

On 1/14/2014 10:11 AM, Jim J. Jewett wrote: Virtual subclass ASCIIStructuredBytes You would first have to define what you meant by a virtual subclass, and that somewhere would have to be linked every place you use the term, because it is a new term. Why not just call the sections of the doc

Re: [Python-Dev] magic method __bytes__

On Tue, Jan 14, 2014 at 10:58:49AM -0500, R. David Murray wrote: > On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman wrote: > > Has anyone actually used __bytes__ yet? What for? > > bytes(email.message.Message()) returns the message object serialized to > "wire format". > > --David > > PS: I've

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

Even though I’m not a core dev, I happen to work with cpython source code quite a lot, whether it’s me working on a C extension, or just digging it for some obscure details of how python works. And what I want to say is that cpython sources are great. They are easy to understand even for people wh

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

Nick Coghlan wrote: On 15 Jan 2014 08:00, "Greg Ewing" > wrote: > > If so, would it help if asciistr were a built-in > type, so that other things could be made aware of > it? That way lies the Python 2 text model, and we're not going there. It's probabl

Re: [Python-Dev] PEP 460 reboot

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 IMO good tradition of producing (slightly) wrong output in favor of more strict behavior. Cons

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

On 01/14/2014 01:38 PM, Raymond Hettinger wrote: FWIW, I think everyone should place a lot of weight on Serhiy's comments and suggestions. His reasoning is clear and compelling. And the thoughts are all soundly based on extensive experience with the clinic's effect on the C source code. One

Re: [Python-Dev] PEP 460 reboot

Ethan Furman wrote: On 01/14/2014 10:11 AM, Jim J. Jewett wrote: But in terms of explaining the text model, that separation is important enough that (2) It *may* be worth creating a virtual split in the documentation. I think (2) is a great idea. I don't think it's suc

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

15.01.14 00:40, Guido van Rossum написав(ла): I think of PEP 460 as the strict version and PEP 461 as the lenient version. I don't think it makes sense to have more variants. So please collaborate with whichever you like best. :-) Perhaps the consensus will be PEP 460.5? Or PEP 460.3, or may be

[Python-Dev] The asciistr problem

Guido van Rossum wrote: I understand that '&' here stands for "any arbitrary combination", but what about searches? Given that asciistr's base class is str, won't it still blow up if you try to use it as an argument to e.g. bytes.startswith()? Equality tests also sound problematic; is b'x' == asc

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

On Tue, Jan 14, 2014 at 1:37 PM, Nick Coghlan wrote: > Yep - that's why I consider asciistr to be firmly in the "power tool" > category. If you know what you're doing, it should let you write hybrid API > code that is just as concise as Python 2, but it's also far more error prone > than the core

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

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 292 string templates in any way, shape or for

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

14.01.14 23:38, Raymond Hettinger написав(ла): On Jan 14, 2014, at 9:12 PM, Antoine Pitrou mailto:solip...@pitrou.net>> wrote: I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on the current "sprinkled everywhere" approach. I concur with Antoine except that I'm a ful

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

I think of PEP 460 as the strict version and PEP 461 as the lenient version. I don't think it makes sense to have more variants. So please collaborate with whichever you like best. :-) On Tue, Jan 14, 2014 at 1:11 PM, Ethan Furman wrote: > On 01/14/2014 01:05 PM, Brett Cannon wrote: > >> On Tue,

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

On 15 Jan 2014 08:23, "Ethan Furman" wrote: > > On 01/14/2014 02:17 PM, Nick Coghlan wrote: >> >> >> On 15 Jan 2014 07:36, "Ethan Furman" > wrote: >>> >>> >>> On 01/14/2014 12:57 PM, Antoine Pitrou wrote: On Tue, 14 Jan 2014 11:56:25 -0800 Ethan Furman mailto:et...@stoneleaf.us

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

On 01/14/2014 01:38 PM, Raymond Hettinger wrote: On Jan 14, 2014, at 9:12 PM, Antoine Pitrou > wrote: I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on the current "sprinkled everywhere" approach. I concur with Antoine except that I'm

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

On 01/14/2014 12:51 PM, Ethan Furman wrote: I checked the README, the current file, and the buffered files. My preferences from highest to lowest: - modified buffer approach - buffer approach - side file Could you put that in the form of numbers from +1 to -1? I'm literally making a

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

On 01/14/2014 02:17 PM, Nick Coghlan wrote: On 15 Jan 2014 07:36, "Ethan Furman" mailto:et...@stoneleaf.us>> wrote: On 01/14/2014 12:57 PM, Antoine Pitrou wrote: On Tue, 14 Jan 2014 11:56:25 -0800 Ethan Furman mailto:et...@stoneleaf.us>> wrote: %s, because it is the most general, has the

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

On 15 Jan 2014 08:14, "Greg Ewing" wrote: > > Guido van Rossum wrote: >> >> Actually, Nick explained that asciistr() + asciistr() returns str, > > > That part seems wrong to me, because it means that > you can't write polymorphic byte/string functions > that are composable. > > I would be -1 on th

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

On 15 Jan 2014 07:36, "Ethan Furman" wrote: > > On 01/14/2014 12:57 PM, Antoine Pitrou wrote: >> >> On Tue, 14 Jan 2014 11:56:25 -0800 >> Ethan Furman wrote: >>> >>> >>> %s, because it is the most general, has the most convoluted resolution: >>> >>> - input type is bytes? >>> pass it st

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

Guido van Rossum wrote: Actually, Nick explained that asciistr() + asciistr() returns str, That part seems wrong to me, because it means that you can't write polymorphic byte/string functions that are composable. I would be -1 on that, and prefer that asciistr + asciistr --> asciistr. -- Greg

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

Am 14.01.2014 21:22, schrieb Larry Hastings: > > On 01/11/2014 07:35 PM, Larry Hastings wrote: >> >> On 01/08/2014 07:08 AM, Barry Warsaw wrote: >>> How hard would it be to put together some sample branches that provide >>> concrete examples of the various options? >>> >>> My own opinion could eas

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

On 15 Jan 2014 08:00, "Greg Ewing" wrote: > > Guido van Rossum wrote: >> >> def spam(a): >> r = asciistr('(') >> if a: r += a.strip() >> r += asciistr(')') >> return r >> >> The general fix would be to add >> >> else: r += a[:0] > > > The awkwardness might be reducable if asci

Re: [Python-Dev] PEP 460 reboot

On 1/14/2014 4:46 AM, Nick Coghlan wrote: The one remaining way I could potentially see a formatb method working is along the lines of what Glenn (I think) suggested: just like struct definitions, the formatb specifier would have to consist*solely* of substitution fields. However, that's getting

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

Guido van Rossum wrote: def spam(a): r = asciistr('(') if a: r += a.strip() r += asciistr(')') return r The general fix would be to add else: r += a[:0] The awkwardness might be reducable if asciistr let you write something like r = asciistr('(', a) meaning "give me

Re: [Python-Dev] PEP 460 reboot

Let me answer you both since the issues are related. On 1/14/2014 7:46 AM, Nick Coghlan wrote: Guido van Rossum writes: > And that is precisely my point. When you're using a format string, Bytes interpolation uses a bytes format, or a byte string if you will, but it should not be thought o

Re: [Python-Dev] PEP 460 reboot

On 01/14/2014 01:17 PM, Mark Lawrence wrote: On 14/01/2014 20:54, Guido van Rossum wrote: On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote: In Py2, because '%15s' can actually take 17 characters, I have to use '%15s' % data_value[:15] everywhere. Wow. I thought there would be some combi

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

On Tue, Jan 14, 2014 at 2:54 PM, Larry Hastings wrote: > I will consider you a +1 on the "buffer" approach and NaN on the other > approaches. Oops, I'll give you some real numbers: -1 _pickle.original.c +1 _pickle.using-buffer.c +0 _pickle.using-modified-buffer.c +1 _pickle.using-multiple-buffe

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

On Tue, 14 Jan 2014 13:07:57 -0800 Ethan Furman wrote: > > Meaning any bytes or bytes-subtype will support the Py_buffer protocol, and > this should be the first thing we try? > > Sounds good. > > For that matter, should the first test be "does this object support > Py_buffer" and not worry a

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

On January 14, 2014 at 4:36:00 PM, Ethan Furman (et...@stoneleaf.us) wrote: > > On 01/14/2014 12:57 PM, Antoine Pitrou wrote: > > On Tue, 14 Jan 2014 11:56:25 -0800 > > Ethan Furman wrote: > >> > >> %s, because it is the most general, has the most convoluted > resolution: > >> > >> - input type i

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

On Jan 14, 2014, at 9:12 PM, Antoine Pitrou wrote: > I'm +1 on the sidefile approach. +0 on the various buffer approaches. > -0.5 on the current "sprinkled everywhere" approach. I concur with Antoine except that I'm a full -1 on commingling generated code with hand edited code. Sprinked every

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

On 15 Jan 2014 04:16, "Guido van Rossum" wrote: > > [Other readers: asciistr is at https://github.com/jeamland/asciicompat] > > On Mon, Jan 13, 2014 at 11:44 PM, Nick Coghlan wrote: > > Right, asciistr is designed for a specific kind of hybrid API where > > you want to accept binary input (and pr

Re: [Python-Dev] PEP 460 reboot

On 2014-01-14 20:54, Guido van Rossum wrote: On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote: On 01/14/2014 10:52 AM, Guido van Rossum wrote: Which reminds me. Quite a few people have spoken out in favor of loud failures rather than silent "wrong" output. But I think that in the specific

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

On 01/14/2014 12:57 PM, Antoine Pitrou wrote: On Tue, 14 Jan 2014 11:56:25 -0800 Ethan Furman wrote: %s, because it is the most general, has the most convoluted resolution: - input type is bytes? pass it straight through It should try to get a Py_buffer instead. Meaning any byte

Re: [Python-Dev] PEP 460 reboot

On 01/14/2014 01:15 PM, Eric V. Smith wrote: On 1/14/2014 3:54 PM, Guido van Rossum wrote: On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote: In Py2, because '%15s' can actually take 17 characters, I have to use '%15s' % data_value[:15] everywhere. Wow. I thought there would be some combi

Re: [Python-Dev] PEP 460 reboot

On Jan 14, 2014, at 10:52 AM, Guido van Rossum wrote: >Which reminds me. 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 IMO good >tradition of producing (slightly)

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan wrote: The mini-language parser has to assume in encoding in order to interpret the format string, and that's *all* done assuming an ASCII compatible format string (which must make life interesting if you try to use an ASCII incompatible coding cookie for your source code I don't t

Re: [Python-Dev] PEP 460 reboot

On 14/01/2014 20:54, Guido van Rossum wrote: On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote: In Py2, because '%15s' can actually take 17 characters, I have to use '%15s' % data_value[:15] everywhere. Wow. I thought there would be some combination using %.15s but I can't get that to wor

Re: [Python-Dev] PEP 460 reboot

On 1/14/2014 3:54 PM, Guido van Rossum wrote: > On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote: >> In Py2, because '%15s' can actually take 17 characters, I have to use '%15s' >> % data_value[:15] everywhere. > > Wow. I thought there would be some combination using %.15s but I can't > get t

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

On Tue, 14 Jan 2014 12:22:12 -0800 Larry Hastings wrote: > > https://bitbucket.org/larry/clinic-buffer-samples/src > > In it I converted Modules/_pickle.c four different ways. There's a > README, please read it. I'm +1 on the sidefile approach. +0 on the various buffer approaches. -0.5 on

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

On 01/14/2014 12:22 PM, Larry Hastings wrote: I have now received exactly zero feedback about the prototype, which suggests people aren't using it. In an attempt to jump-start this conversation, I've created a new repository containing the "concrete examples of the various options" that Barry

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

On 01/14/2014 01:05 PM, Brett Cannon wrote: On Tue, Jan 14, 2014 at 2:55 PM, 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. Are we going down the PEP route with the various idea

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

On Tue, Jan 14, 2014 at 2:55 PM, 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. > Are we going down the PEP route with the various ideas? Guido, do you want one from me as well

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

On Tue, Jan 14, 2014 at 3:22 PM, Larry Hastings wrote: > > On 01/11/2014 07:35 PM, Larry Hastings wrote: > > > On 01/08/2014 07:08 AM, Barry Warsaw wrote: > > How hard would it be to put together some sample branches that provide > concrete examples of the various options? > > My own opinion coul

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

On Tue, 14 Jan 2014 11:56:25 -0800 Ethan Furman wrote: > > %s, because it is the most general, has the most convoluted resolution: > >- input type is bytes? > pass it straight through It should try to get a Py_buffer instead. >- input type is numeric? > use its __xxx__ [1] [2

Re: [Python-Dev] PEP 460 reboot

On Tue, Jan 14, 2014 at 12:13 PM, Ethan Furman wrote: > On 01/14/2014 10:52 AM, Guido van Rossum wrote: >> >> Which reminds me. 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

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

On 01/14/2014 12:48 PM, Zachary Ware wrote: On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings wrote: I have now received exactly zero feedback about the prototype, which suggests people aren't using it. Oops, I had half a post written about this two days ago, but never got it posted. I did som

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

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~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-d

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

On Tue, Jan 14, 2014 at 2:22 PM, Larry Hastings wrote: > I have now received exactly zero feedback about the prototype, which > suggests people aren't using it. Oops, I had half a post written about this two days ago, but never got it posted. I did some experimenting on winreg.c (see http://hg.p

Re: [Python-Dev] PEP 460 reboot

On 01/14/2014 10:52 AM, Guido van Rossum wrote: Which reminds me. 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 IMO good tradition of producing (slightly) wrong ou

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

On 01/11/2014 07:35 PM, Larry Hastings wrote: On 01/08/2014 07:08 AM, Barry Warsaw wrote: How hard would it be to put together some sample branches that provide concrete examples of the various options? My own opinion could easily be influenced by having some hands-on time with actual code, a

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

Duh. Here's the text, as well. ;) PEP: 461 Title: Adding % and {} formatting to bytes Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2014-01-13 Python-Version: 3.5 Post-History: 2014-01-13 Resolution: Abst

Re: [Python-Dev] PEP 460 reboot

On Tue, Jan 14, 2014 at 12:04 PM, Eric V. Smith wrote: > On 01/14/2014 01:52 PM, Guido van Rossum wrote: > >> But the way to arrive at this behavior without duplicating a whole lot >> of code seems to be to call the existing text-based __format__ API and >> convert the result to bytes -- for numbe

Re: [Python-Dev] PEP 460 reboot

Personally I wouldn't add any words suggesting or referring to the option of creation another class for this purpose. You wouldn't recommend subclassing dict for constraining the types of keys or values, would you? On Tue, Jan 14, 2014 at 11:43 AM, Jim J. Jewett wrote: > > > > Greg Ewing replied:

Re: [Python-Dev] PEP 460 reboot

On 01/14/2014 01:52 PM, Guido van Rossum wrote: > But the way to arrive at this behavior without duplicating a whole lot > of code seems to be to call the existing text-based __format__ API and > convert the result to bytes -- for numbers this should be safe (their > formatting produces just ASCII

Re: [Python-Dev] Byte/text documentation improvements (was: PEP 460 reboot)

On Tue, 14 Jan 2014 11:43:16 -0800, "Jim J. Jewett" wrote: > Greg Ewing replied: > > >> ... ASCII compatible binary data is a > >> *subset* of arbitrary binary data. > > I wrote: > > > But in terms of explaining the text model, that > > separation is important enough that > > >(2) It *ma

Re: [Python-Dev] PEP 460 reboot

Greg Ewing replied: >> ... ASCII compatible binary data is a >> *subset* of arbitrary binary data. I wrote: > But in terms of explaining the text model, that > separation is important enough that >(2) It *may* be worth creating a virtual > split in the documentation. (rough ske

Re: [Python-Dev] PEP 460 reboot

On Tue, Jan 14, 2014 at 1:52 PM, Guido van Rossum wrote: > On Tue, Jan 14, 2014 at 9:45 AM, Chris Barker wrote: >> On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov >> wrote: >>> >>> - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result. >> >> >> please no -- that's the source of a lot o

Re: [Python-Dev] PEP 460 reboot

On Tue, 14 Jan 2014 10:52:05 -0800 Guido van Rossum wrote: > Would you rather raise an exception, truncate the > value, or mess up the formatting? All languages newer than Fortran > that I've used have chosen the latter, and I still agree it's a good > idea. Well that's useful when printing out h

Re: [Python-Dev] [Python-checkins] peps: Fill in PEP number (461).

I think this was supposed to be 461, not 460 =) On Tue, Jan 14, 2014 at 2:12 PM, guido.van.rossum < python-check...@python.org> wrote: > http://hg.python.org/peps/rev/a25f48998ad3 > changeset: 5346:a25f48998ad3 > user:Guido van Rossum > date:Tue Jan 14 11:12:09 2014 -0800 > su

Re: [Python-Dev] PEP 460 reboot

On 1/14/2014 1:11 PM, Jim J. Jewett wrote: But in terms of explaining the text model, that separation is important enough that (1) We should be reluctant to strengthen the "its really just ASCII" messages. (2) It *may* be worth creating a virtual split in the doc

Re: [Python-Dev] PEP 460 reboot

On Tue, Jan 14, 2014 at 9:45 AM, Chris Barker wrote: > On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov > wrote: >> >> - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result. > > > please no -- that's the source of a lot of pain in py2 now. > > having a failure as a result of the value, r

Re: [Python-Dev] PEP 460 reboot

On 01/14/2014 10:11 AM, Jim J. Jewett wrote: But in terms of explaining the text model, that separation is important enough that (2) It *may* be worth creating a virtual split in the documentation. I think (2) is a great idea. I'm willing ot work on (2) if there is general

Re: [Python-Dev] PEP 460 reboot

On Tue, Jan 14, 2014 at 9:29 AM, Yury Selivanov wrote: > - Try str(), and do ".encode(‘ascii’, ‘stcict’)” on the result. > please no -- that's the source of a lot of pain in py2 now. having a failure as a result of the value, rather than the type, of an object just makes hard-to-test for bugs.

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

[Other readers: asciistr is at https://github.com/jeamland/asciicompat] On Mon, Jan 13, 2014 at 11:44 PM, Nick Coghlan wrote: > Right, asciistr is designed for a specific kind of hybrid API where > you want to accept binary input (and produce binary output) *and* you > want to accept text input (

Re: [Python-Dev] PEP 460 reboot

Nick Coghlan wrote: >> Arbitrary binary data and ASCII compatible binary data are *different >> things* and the only argument in favour of modelling them with a single >> type is because Python 2 did it that way. Greg Ewing replied: > I would say that ASCII compatible binary data is a > *sub

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

On Tue, Jan 14, 2014 at 7:59 AM, Guido van Rossum wrote: > Here's an example of what I mean: I sent that off without proofreading, and I also got one detail about asciistr() wrong. Here are some corrections. > def spam(a): > r = asciistr('(') > if a: r += a.strip() > r += asciistr(')

Re: [Python-Dev] PEP 460 reboot

On January 14, 2014 at 12:47:35 PM, Brett Cannon (br...@python.org) wrote: > > On Tue, Jan 14, 2014 at 12:29 PM, Yury Selivanov wrote: > > > Brett, > > > > > > I like your proposal. There is one idea I have that could, > > perhaps, improve it: > > > > > > 1. “%s" and “{}” will continue to wor

Re: [Python-Dev] PEP 460 reboot

On Tue, Jan 14, 2014 at 12:29 PM, Yury Selivanov wrote: > Brett, > > > I like your proposal. There is one idea I have that could, > perhaps, improve it: > > > 1. “%s" and “{}” will continue to work for bytes and bytearray in > the following fashion: > > - check if __bytes__/Py_buffer supported.

Re: [Python-Dev] PEP 460 reboot

Brett, I like your proposal.  There is one idea I have that could, perhaps, improve it: 1. “%s" and “{}” will continue to work for bytes and bytearray in the following fashion:  - check if __bytes__/Py_buffer supported.  - if it is, check that the bytes are strictly in the printable     ASCII-

Re: [Python-Dev] PEP 460 reboot

On Mon, Jan 13, 2014 at 5:14 PM, Guido van Rossum wrote: > On Mon, Jan 13, 2014 at 2:05 PM, Brett Cannon wrote: > > I have been going on the assumption that bytes.format() would change what > > '{}' meant for itself and would only interpolate bytes. That convenient > > between Python 2 and 3 sin

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

On Tue, Jan 14, 2014 at 12:20 AM, Greg Ewing wrote: > Guido van Rossum wrote: >> >> I've now looked at asciistr. (Thanks Glenn and Ethan for the link.) >> >> Now that I (hopefully) understand it, I'm worried that a text >> processing algorithm that uses asciistr might under hard-to-predict >> circ

Re: [Python-Dev] magic method __bytes__

On Mon, 13 Jan 2014 17:38:38 -0800, Ethan Furman wrote: > Has anyone actually used __bytes__ yet? What for? bytes(email.message.Message()) returns the message object serialized to "wire format". --David PS: I've always thought of "wire format" as *including* files...a file is a just a "wire" w

Re: [Python-Dev] cpython (merge 2.7 -> 3.1): complain when nbytes > buflen to fix possible buffer overflow (closes #20246)

On Tue, Jan 14, 2014, at 01:17 AM, Ned Deily wrote: > In article <3f3jh11tmgz7...@mail.python.org>, > benjamin.peterson wrote: > > http://hg.python.org/cpython/rev/715fd3d8ac93 > > changeset: 88454:715fd3d8ac93 > > branch: 3.1 > > parent: 86777:b1ddcb220a7f > > parent: 88453:876

Re: [Python-Dev] PEP 460 reboot

On 14 January 2014 19:54, Stephen J. Turnbull wrote: > Guido van Rossum writes: > > And that is precisely my point. When you're using a format string, > > all of the format string (not just the part between { and }) had > > better use ASCII or an ASCII superset. And this (rightly) > > constrai

Re: [Python-Dev] PEP 460 reboot

Guido van Rossum writes: > Of course, nobody in their right mind would use a format string > containing UTF-16 or EBCDIC. How about Shift JIS and Big 5 (traditionally "mandated by Microsoft" in their respective regions, with Shift JIS still overwhelmingly popular) and GB* ("GB18030 is not just

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

On 14 Jan 2014 19:11, "Stephen J. Turnbull" wrote: > > Nick Coghlan writes: > > > "Give up" makes it sound like I got tired of arguing without being > > convinced rather than admitting I was just plain wrong. > > I thought it was something in between (you explicitly said "lenient > PEP 460" does

Re: [Python-Dev] cpython (merge 2.7 -> 3.1): complain when nbytes > buflen to fix possible buffer overflow (closes #20246)

In article <3f3jh11tmgz7...@mail.python.org>, benjamin.peterson wrote: > http://hg.python.org/cpython/rev/715fd3d8ac93 > changeset: 88454:715fd3d8ac93 > branch: 3.1 > parent: 86777:b1ddcb220a7f > parent: 88453:87673659d8f7 > user:Benjamin Peterson > date:Mon Jan

  1   2   >