The following issues in ElementTree still exist in the latest release
candidate all have small patches to fix the issue. Any chance of
getting these in before the final release?
http://bugs.python.org/issue6231
http://bugs.python.org/issue6233
http://bugs.python.org/issue2746
--
Neil Muller
Neil Muller drnlmuller+python at gmail.com writes:
The following issues in ElementTree still exist in the latest release
candidate all have small patches to fix the issue. Any chance of
getting these in before the final release?
http://bugs.python.org/issue6231
Greg Ewing wrote:
Even if you don't mention it explicitly, its
existence shows through in the fact that there
is an arbitrary limit on the amount you can
peek ahead, and that limit needs to be documented
so that people can write correct programs.
This is true of both kinds of peeking, so I
Hello,
I am looking for alternatives to Josiah Carlson's asynchronous I/O patch for
subprocess.Popen. While his patch seems to work well, it relies on pywin32
which is not part of the standard Python library. If I cannot find an
alternative, I will be using cTypes with the parts of Mark Hammond's
Eric Pruitt schrieb:
Hello,
I am looking for alternatives to Josiah Carlson's asynchronous I/O patch for
subprocess.Popen. While his patch seems to work well, it relies on pywin32
which is not part of the standard Python library. If I cannot find an
alternative, I will be using cTypes with
On Sat, Jun 13, 2009 at 9:40 AM, Facundo
Batistafacundobati...@gmail.com wrote:
How about a nice 'n shiny context wrapper for the pipe:
I'll do this!
Thank you for the suggestion!
Boo, I can not take this approach, neither the previous one.
The reason is very specific for subprocess.py...
Thanks for the lead. I have the pywin32 source code and have found the files
that appear to contain the code I need inside of some *.i files. After a
bit of Googling and paying attention to the blatantly obvious *.cpp files, I
realized Hammond's code is written in C++ whereas Python uses C. I am
Lucas P Melo wrote:
The problem is that the chosen
method to accomplish it would read 2 symbols (bytes) ahead and this guy
is using peek() to grab these 2 bytes. The program will seem to work
correctly most of the time, but on the 4095th byte read, he would grab 1
byte at most using peek()
Backwards compatibility seems to be an issue that arises a lot here. I
think we all have an idea of it is, but we need some hard place to
point to. So here's my attempt:
PEP: 387
Title: Backwards Compatibility Policy
Version: $Revision$
Last-Modified: $Date$
Author: Benjamin Peterson
