Mailman 3 January 2014 - Python-Dev

Re: [Python-Dev] PEP 461 updates
by Ethan Furman Jan. 16, 2014

Jan. 16, 2014

On 01/16/2014 04:49 AM, Michael Urman wrote: > On Thu, Jan 16, 2014 at 1:52 AM, Ethan Furman <ethan(a)stoneleaf.us> wrote: >>> Is this an intended exception to the overriding principle? >> >> >> Hmm, thanks for spotting that. Yes, that would be a value error if anything >> over 255 is used, both currently in Py2, and for bytes in Py3. As Carl >> suggested, a little more explanation is needed in the PEP. > > FYI, note that str/unicode … [View More]

1 0

Re: [Python-Dev] Common subset of python 2 and python 3
by Markus Unterwaditzer Jan. 16, 2014

Jan. 16, 2014

On Wed, Jan 15, 2014 at 01:22:44PM +0100, "Martin v. Löwis" wrote: > Am 12.01.14 18:39, schrieb Nachshon David Armon: > >>> I propose that this new version of python use the python 3 unicode model. > >>> As the version of python will be fully compatible with both python 2 and > >>> with python 3 but NOT necsesarily with all existing code in either. It is > >>> designed as a porting tool only. > > I don't think that it is possible to … [View More]

1 0

PEP 460 reboot
by Guido van Rossum Jan. 16, 2014

Jan. 16, 2014

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 aren't necessarily ASCII. I think that's a misunderstanding of the intention of the bytes type. The key reason for introducing a separate bytes type in Python 3 is to avoid *mixing* bytes and text. … [View More]This aims to avoid the classic Python 2 Unicode failure, where str+unicode fails or succeeds based on whether str contains non-ASCII characters or not, which means it is easy to miss in testing. Properly written code in Python 3 will fail based on the *type* of the objects, not based on their contents. Content-based failures are still possible, but they occur in typical "boundary" operations such as encode/decode. But this does not mean the bytes type isn't allowed to have a noticeable bias in favor of encodings that are ASCII supersets, even if not all bytes objects contain such data (e.g. image data, compressed data, binary network packets, and so on). IMO it's totally fine and consistent if b'%d' % 42 returns b'42' and also for b'{}'.format(42) to return b'42'. There are numerous places where bytes are already assumed to use an ASCII superset: - byte literals: b'abc' (it's a syntax error to have a non-ASCII character here) - the upper() and lower() methods modify the ASCII letter positions - int(b'42') == 42, float(b'3.14') == 3.14 I looked through the example code I recently write for asyncio (which uses bytes for all data read or written). There are several places where I have to make a clumsy detour via text strings because I need to include an ASCII-encoded decimal integer (e.g. the Content-Length header) or a hex-encoded one (e.g. for Transfer-Encoding: chunked). Those detours aren't needed for parsing because int() accepts bytes just fine. I also note that the behavior of the re module is perfect: if the pattern is bytes, it can only match bytes and the extracted data is bytes, and ditto for text -- so it supports both types but doesn't allow mixing them. The urllib module does this too -- at considerable cost in its implementation, but it's the right thing, because there really are good cases to be made for treating URLs as text as well as for treating them as bytes (as with filenames, command line arguments, and environment variables). I'm sad that the json module in Python 3 doesn't support bytes at all, but at least it is consistent -- it always produces text in ASCII encoding (by default). The same applies to the http module, which IIUC adheres to the standard by treating headers as Latin-1. -- --Guido van Rossum (python.org/~guido) [View Less]

25 146

Signature of function with default value uncapturable in Python and C
by Vajrasky Kok Jan. 16, 2014

Jan. 16, 2014

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 you omit the times argument: >>> list(repeat('a')) ... unlimited of a .... sometimes it can hang your machine .... In the C code it self, the default … [View More]

2 1

Common subset of python 2 and python 3
by Nachshon David Armon Jan. 15, 2014

Jan. 15, 2014

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 if there were a version of python that supported ONLY the features found both in python 2 and python 3. It should be a developer only version of python. It should use unicode strings and require … [View More]

8 12

Changing Clinic's output
by Antoine Pitrou Jan. 15, 2014

Jan. 15, 2014

Hello, Several core developers a bit unhappy with the way Argument Clinic currently scatters generated code into hand-written C modules. The opinion is that it makes C files more confusing and annoying to navigate through. Several solutions have been proposed: - move all generated code to separate C files, which would then be #included'd into the main module file - gather all generated code to a single place in the C module file, for example near the end (Larry's "accumulator" idea) - … [View More]

18 55

Argument Clinic Derby update
by Larry Hastings Jan. 15, 2014

Jan. 15, 2014

The Derby is moving forward, and I have maybe a half-dozen contributors so far. They've made a small dent in making the conversion but I'd have to say it's going slowly. We could use more people contributing patches! To the contributors with patches that are stalled in the tracker: Sorry, but there are only so many hours in the day. I really am spending all day on this, every day, but I've also been adding new features in response to user requests and that's eaten a lot of my time. I'… [View More]

1 0

Binding problem
by Rob Ward Jan. 15, 2014

Jan. 15, 2014

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 <Return> Here is the snippet (butCol is a Frame widget to put buttons,labels and text entry down LHS) KS1=StringVar() KS1.set("Key is ??") butCol.ks1 =Label(butCol,textvariable=KS1).grid(column=0,row=18,sticky=(N,W)) myKey = [0,2,4,5,7,9,11] #Begin in … [View More]

5 4

PEP 460: allowing %d and %f and mojibake
by Victor Stinner Jan. 15, 2014

Jan. 15, 2014

Hi, I'm in favor of adding support of formatting integer and floatting point numbers in the PEP 460: %d, %u, %o, %x, %f with padding and precision (%10d, %010d, %1.5f) and sign (%-i, %+i) but without alternate format ("{:#x}"). %s would also accept int and float for convenience. int and float subclasses would not be handled differently, their __str__ and __format__ would be ignored. Other int-like and float-like types (ex: defining __int__ or __index__) are not supported. Explicit cast would … [View More]

22 107

magic method __bytes__
by Ethan Furman Jan. 15, 2014

Jan. 15, 2014

Has anyone actually used __bytes__ yet? What for? -- ~Ethan~

5 4