Mailman 3 January 2014 - Python-Dev

Re: [Python-Dev] PEP 461 updates
by Ethan Furman 16 Jan '14

16 Jan '14

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 already has another value-dependent > exception with %c. I find the message surprising, as I wasn't aware > Python had a 'char' type: > >>>> '%c' % 'a' > 'a' >>>> '%c' % 'abc' > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: %c requires int or char Python doesn't have a char type, it has str's of length 1... which are usually referred to as char's. ;) -- ~Ethan~

1 0

Re: [Python-Dev] Common subset of python 2 and python 3
by Markus Unterwaditzer 16 Jan '14

16 Jan '14

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 write an interpreter that is fully > compatible for all it accepts. Would you think that the program > > print(repr(2**80).endswith("L")) > > is in the subset that should be supported by both Python 2 and Python 3? IMO Python 2 and 3 do have this part in common when you talk about valid syntax and available methods and functions, but not in terms of behavior. I think a new proposed Python version should simply crash on your example. I'm kind-of playing devil's advocate here because i agree with previous posters that such a Python version is unneccessary with tox and "python2 -3" > > Notice that it prints "True" in Python 2 and "False" in Python 3. So if > this common-version interpreter *rejects* the above program, which > operation (**, repr, endswith) would you want to ban from subset? Warnings about using certain string methods on repr() might be a neat thing to add to "python -3" or static analysis tools. > > Regards, > Martin > > _______________________________________________ > Python-Dev mailing list > Python-Dev(a)python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/markus%40unterwaditzer.n…

1 0

PEP 460 reboot
by Guido van Rossum 16 Jan '14

16 Jan '14

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. 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)

25 146

Signature of function with default value uncapturable in Python and C
by Vajrasky Kok 16 Jan '14

16 Jan '14

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 value of variable handling times argument is -1. It checks how many arguments you give to the function. So if you give -1 directly: >>> list(repeat('a', -1)) [] Negative value of times argument means 0. So what is the correct signature of this function? The value is not really capturable in Python and C. repeat(object [,times = unlimited]) ???? Can we do this in Clinic? If not, should we? Vajrasky

2 1

Common subset of python 2 and python 3
by Nachshon David Armon 16 Jan '14

16 Jan '14

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 that people use the from __future__ syntax so that anything written in it will work in python 2.7 and in python 3.3+. Regarding name changes of standard library modules it should support the new stuff and have helper functions and guides that make the old modules likethe new ones. it should encourage using backports of the new standard library modules like enum so that developers are not stuck for features. 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 suggest that this new python version should be called python 2 and 9 tenths. Is it worth it for me to write a pep that suggests this?

8 12

Changing Clinic's output
by Antoine Pitrou 16 Jan '14

16 Jan '14

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) - prefix all Clinic-generated lines with a recognizable marker, e.g. "/* AC */" What do you think? Regards Antoine.

18 55

Argument Clinic Derby update
by Larry Hastings 16 Jan '14

16 Jan '14

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'm getting to the patches in the order they arrived in my mailbox. Please sit tight, I'll get to yours, and I really do appreciate your contribution. If you have more time to contribute, please consider writing more patches. It really will help! And I guess I could also use some volunteers to review patches, too! //arry/

1 0

Binding problem
by Rob Ward 15 Jan '14

15 Jan '14

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 the key of C KS2 =StringVar() KS2.set("C") butCol.ks2 =Entry(butCol,width=20,textvariable=KS2).grid(column=0,row=19,sticky=(N,W)) The above lines all render correctly, but will not trigger off "entry" of data at all on <Return> Adding the following line just crashes. butCol.ks2.bind("<Return>",chooseKey) I downloaded the Python 3 package from the recommended site last week to begin this project (it was previously working OK in Skulptor, but I was not prepared to develop it any further in that environment, though it was an excellent starting environment). So I believe the Python language installed is up todate. I have not previously installed Python so it should be "clean". If you could give any direct advice I would be very grateful or if you can direct me to your best "forum" site maybe I could use that. One overall observation that has frustrated me is how toi search for information that relates to Python3 and the latest tkinter modules. I kept finding old python or old Tkinter or combinations of both. Wrorking my way through this was very time consuming and rarely productive. Is there any advice on how to get the "latest" information off the WWW? Cheers, Rob Ward PS In my state of eternal optimism I have attached the whole file :-) PPS I have done some OOP in the past but not keen to jump in at the moment.

5 4

PEP 460: allowing %d and %f and mojibake
by Victor Stinner 15 Jan '14

15 Jan '14

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 be required. For %s, the choice between string and number is made using "(PyLong_Check() || PyFloat_Check())". If you agree, I will modify the PEP. If Antoine disagree, I will fork the PEP 460 ;-) --- %s should not support precision (ex: %.100s), use Unicode for that. --- The PEP 460 should not reintroduce bytes+unicode, implicit decoding or implement encoding. b'x=%s' % 10 is well defined, it's pure bytes. If you consider that bytes should not contain text, why does the bytes type have methods like isalpha() or upper()? And why binary files have a readline() method? A "line" doesn't mean anything in pure bytes. It's an example of "practicality beats purity". Python 3 should not enforce Unicode if the developers *chose* to use bytes to handle mixed binary/text protocols like HTTP. But I'm against of adding "%r" and "%a" because they use Unicode and would require an implicit encoding. type(ascii(obj)) is str, not bytes. If you really want to use repr() and ascii(), encode the result explicitly. Victor

22 107

magic method __bytes__
by Ethan Furman 15 Jan '14

15 Jan '14

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

5 4