Mailman 3 November 2013 - Python-ideas

Re: [Python-ideas] Unicode stdin/stdout
by Draic Kin Nov. 19, 2013

Nov. 19, 2013

On Tue, Nov 19, 2013 at 7:02 PM, <random832(a)fastmail.us> wrote: > On Tue, Nov 19, 2013, at 12:28, Draic Kin wrote: > > Well, if you use the textio object than there are no problems and you > > couldn't use buffered or raw io at all with the other approach. If you > > try > > to read one byte from raw io, it just returns b''. > > I get that, but my understanding is that this implies EOF. > Does it? If so then rawio.read(1) should raise en exception … [View More]

1 0

A nice __repr__ for the ast.* classes?
by Haoyi Li Nov. 19, 2013

Nov. 19, 2013

Wouldn't it be nice if this >>> import ast >>> print repr(ast.parse("(1 + 1)").body[0].value) <_ast.BinOp object at 0x0000000001E94B38> printed something more useful? >>> print repr(ast.parse("(1 + 1)").body[0].value) BinOp(left=Num(n=1), op=Add(), right=Num(n=1)) I've been doing some work on macropy <https://github.com/lihaoyi/macropy>, which uses the ast.* classes extensively, and it's annoying that we have to resort to dirty-tricks like monkey-… [View More]

5 5

Re: [Python-ideas] Unicode stdin/stdout (was: Re: python 3.3repr)
by Draic Kin Nov. 19, 2013

Nov. 19, 2013

(Sorry for posting twice, forgot to add the list to Cc.) On Tue, Nov 19, 2013 at 6:08 PM, <random832(a)fastmail.us> wrote: > On Tue, Nov 19, 2013, at 4:46, drekin(a)gmail.com wrote: > > I really wanted to be able to write Unicode in Windows console, so I have > > written the following code: http://bugs.python.org/file31756/streams.py > > (based on other samples of code I found), in connection with > > http://bugs.python.org/issue1602 . It addresses the design … [View More]

1 0

Re: [Python-ideas] Unicode stdin/stdout
by Robin Becker Nov. 19, 2013

Nov. 19, 2013

On 18/11/2013 11:47, Robin Becker wrote: ........... > #c:\python33\lib\site-packages\sitecustomize.py > import sys, codecs > sys.stdout = codecs.getwriter("utf-8")(sys.stdout.detach()) > sys.stderr = codecs.getwriter("utf-8")(sys.stderr.detach()) ........ it seems that the above needs extra stuff to make some distutils logging work etc etc; so now I'm using sitecustomize.py containing import sys, codecs sys.stdout = codecs.getwriter("utf-8")(sys.stdout.detach()) sys.stdout.… [View More]

6 7

Re: [Python-ideas] [Python-Dev] PyParallel: alternate async I/O and GIL removal
by Guido van Rossum Nov. 17, 2013

Nov. 17, 2013

Trent, I watched your video and read your slides. (Does the word "motormouth" mean anything to you? :-) Clearly your work isn't ready for python-dev -- it is just too speculative. I've moved python-dev to BCC and added python-ideas. It possibly doesn't even belong on python-ideas -- if you are serious about wanting to change Linux or other *NIX variants, you'll have to go find a venue where people who do forward-looking kernel work hang out. Finally, I'm not sure why you are so … [View More]confrontational about the way Twisted and Tulip do things. We are doing things the only way they *can* be done without overhauling the entire CPython implementation (which you have proven will take several major release cycles, probably until 4.0). It's fine that you are looking further forward than most of us. I don't think it makes sense that you are blaming the rest of us for writing libraries that can be used today. On Sat, Nov 16, 2013 at 10:13 AM, Trent Nelson <trent(a)snakebite.org> wrote: > Hi folks, > > Video of the presentation I gave last weekend at PyData NYC > regarding PyParallel just went live: https://vimeo.com/79539317 > > Slides are here: > https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploit… > > The work was driven by the async I/O discussions around this time > last year on python-ideas. That resulted in me sending this: > > > http://markmail.org/thread/kh3qgjbydvxt3exw#query:+page:1+mid:arua62vllzugj… > > ....where I attempted to argue that there was a better way of > doing async I/O on Windows than the status quo of single-threaded, > non-blocking I/O with an event multiplex syscall. > > I wasn't successful in convincing anyone at the time; I had no code > to back it up and I didn't articulate my plans for GIL removal at > the time either (figuring the initial suggestion would be met with > enough scepticism as is). > > So, in the video above, I spend a lot of time detailing how IOCP > works on Windows, how it presents us with a better environment than > UNIX for doing asynchronous I/O, and how it paired nicely with the > other work I did on coming up with a way for multiple threads to > execute simultaneously across all cores without introducing any > speed penalties. > > I'm particularly interested to hear if the video/slides helped > UNIX-centric people gain a better understanding of how Windows does > IOCP and why it would be preferable when doing async I/O. > > The reverse is also true: if you still think single-threaded, non- > blocking synchronous I/O via kqueue/epoll is better than the > approach afforded by IOCP, I'm interested in hearing why. > > As crazy as it sounds, my long term goal would be to try and > influence Linux and BSD kernels to implement thread-agnostic I/O > support such that an IOCP-like mechanism could be exposed; Solaris > and AIX already do this via event ports and AIX's verbatim copy of > Windows' IOCP API. > > (There is some promising work already being done on Linux; see > recent MegaPipe paper for an example.) > > Regards, > > Trent. > _______________________________________________ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) [View Less]

6 12

Fwd: [Python-Dev] PyParallel: alternate async I/O and GIL removal
by Armin Rigo Nov. 17, 2013

Nov. 17, 2013

Hi Trent, On Sat, Nov 16, 2013 at 7:13 PM, Trent Nelson <trent(a)snakebite.org> wrote: > Slides are here: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploit… Please stop me if I'm wrong. This allows the Python programmer to run a bunch of new threads in parallel; each new thread has read-only access to all pre-existing objects; all objects created by this new thread must die at the end. Disregarding issues of performance, this seems to be exactly the … [View More]

1 0

Gzip and zip extra field
by Serhiy Storchaka Nov. 17, 2013

Nov. 17, 2013

Gzip files can contains an extra field [1] and some applications use this for extending gzip format. The current GzipFile implementation ignores this field on input and doesn't allow to create a new file with an extra field. ZIP file entries also can contains an extra field [2]. Currently it just saved as bytes in the `extra` attribute of ZipInfo. I propose to save an extra field for gzip file and provide structural access to subfields. f = gzip.GzipFile('somefile.gz', 'rb') f.… [View More]

3 4

Unicode stdin/stdout (was: Re: python 3.3 repr)
by random832＠fastmail.us Nov. 16, 2013

Nov. 16, 2013

Of course, the real solution to this issue is to replace sys.stdout on windows with an object that can handle Unicode directly with the WriteConsoleW function - the problem there is that it will break code that expects to be able to use sys.stdout.buffer for binary I/O. I also wasn't able to get the analogous stdin replacement class to work with input() in my attempts.

2 1

remove coupling between unittest and assertions
by Gregory Salvan Nov. 15, 2013

Nov. 15, 2013

Hi, I would seperate unittest from its assertions. I suggest to create the module "assertions" in stdlib. - it will not change unittest api - it improves decoupling and SOC so other testing library will be able to share a common base code avoiding duplication - it would be great to write guard clauses with more expressive error message like that for example: from assertions import assert_in def my_function(*args, **kwargs): assert_in(''option", kwargs) ... This last point merits more … [View More]

2 1

A suggestion for Python 3 vs Python 2
by Xuancong Wang Nov. 14, 2013

Nov. 14, 2013

Hi python developers, I notice that one major change in python 3 is that it makes 'print' as a standard function, and it will require typing (). I do understand that it makes python language more consistent because most of the python functionalities are implemented as function calls. As you know, reading from and writing to IO is a high frequency operation. By entropy coding theorem (e.g. Huffman coding), an efficient language should assign shorter language code to more frequent tasks. Typing … [View More]

17 33