[Python-Dev] ElementTree issues in python 3.1 rc2
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 drnlmul...@gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ElementTree issues in python 3.1 rc2
Neil Muller 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 > http://bugs.python.org/issue6233 > http://bugs.python.org/issue2746 I've set issue 6233 as a release blocker, since it's an annoying regression compared to trunk. As a side note, I think we have a process problem with externally maintained modules such as etree and json, especially when the maintainer isn't very reactive to bug reports. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1
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 concede that they both break the abstraction. However I think the non-blocking peek breaks it more than the blocking one, because it also brings non-deterministic behaviour. It depends on the point of view. For example, someone is writing a program that must read from any kind of file descriptor and generate the derivation tree of the text read based on some context-free grammar. 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() (despite the existence of say 10k bytes ahead). The blocking definition of peek() would create this hard-to-spot bug. Thus, for him, this behavior would seem non-deterministic. On the other hand, if someone is conscious about the number of raw reads, he would definitely be willing to look into the documentation for any parameters that match his special needs. That's why the non-blocking behavior should be the default one while the blocking behavior should be accessible by choice. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Popen asynchronous input for Windows
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 code that I need, license permitting. Any suggestions are greatly appreciated. Eric ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Popen asynchronous input for Windows
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 the parts of Mark Hammond's code > that I need, license permitting. Any suggestions are greatly appreciated. The subprocess module several wrappers for win32 APIs in Modules/_subprocess.c. You could add the necessary functions. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Avoiding file descriptors leakage in subprocess.Popen()
On Sat, Jun 13, 2009 at 9:40 AM, Facundo Batista 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... after creating the FDs, it forks(), and the behaviour of when closing which descriptors are different for the parent and child processes. If I take Christian approach, the test just hangs. One drawback of the "with" usage is that it closes both FDs at the same time... and in this case this may be a problem, as they're used and closed by different processes in different times... don't know. I also tried the approach of wrapping the FDs with a file object... this *almost* work... but in the case of a problem in the child process, when a traceback should be written through the pipe to the parent, nothing happens (it seems that the GC just closes the object and the info is not transferred). So, I'll stick to the code I submitted to the bug, because even if it's ugly it works. -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Popen asynchronous input for Windows
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 familiar with neither language very well but if I can't find a work-around for Windows asynchronous I/O, I will be learning a bit of both of them. Please feel free to suggest any other ideas that don't rely on my sparse knowledge of C and C++. Eric On Thu, Jun 18, 2009 at 13:32, Christian Heimes wrote: > 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 the parts of Mark Hammond's code > > that I need, license permitting. Any suggestions are greatly appreciated. > > The subprocess module several wrappers for win32 APIs in > Modules/_subprocess.c. You could add the necessary functions. > > Christian > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1
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() That's exactly why I think the blocking version should keep reading until the requested number of bytes is available (or the buffer is full or EOF occurs). In other words, the blocking version should be fully deterministic given knowledge of the buffer size. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] draft pep: backwards compatibility
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 Status: Draft Type: Process Content-Type: text/x-rst Created: 18-Jun-2009 Abstract This PEP outlines Python's backwards compatibility policy. Rationale = As one of the most used programming languages today [#tiobe]_, the Python core language and its standard library play a critcal role in thousands of applications and libraries. This is fantastic; it is probably one of a language designer's most wishful dreams. However, it means the development team must be very careful not to break this existing 3rd party code with new releases. Backwards Compatibility Rules = This policy applys to all public APIs. These include the C-API, the standard library, and the core language including syntax and operation as defined by the reference manual. This is the basic policy for backwards compatibility: * The behavior of an API *must* not change between any two consecutive releases. * A feature cannot be removed without notice between any two consecutive releases. * Addition of a feature which breaks 3rd party libraries or applications should have a large benefit to breakage ratio, and/or the incompatibility should be trival to fix in broken code. Making Incompatible Changes === It's a fact: design mistakes happen. Thus it is important to be able to change APIs or remove misguided features. This is accomplished through a gradual process over several releases: 1. Discuss the change. Depending on the size of the incompatibility, this could be on the bug tracker, python-dev, python-list, or the appropriate SIG. A PEP or similar document may be written. Hopefully users of the affected API will pipe up to comment. 2. Add a warning [#warnings_]_. If behavior is changing, a the API may gain a new function or method to perform the new behavior; old usage should raise the warning. If an API is being removed, simply warn whenever it is entered. DeprecationWarning is the usual warning category to use, but PendingDeprecationWarning may be used in special cases were the old and new versions of the API will coexist for many releases. 3. Wait for a release. 4. See if there's any feedback. Users not involved in the original discussions may comment now after seeing the warning. Perhaps reconsider. 5. The behavior change or feature removal may now be made default or permanent in the next release. Remove the old version and warning. References == .. [#tiobe] TIOBE Programming Community Index http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html .. [#warnings] The warnings module http://docs.python.org/library/warnings.html Copyright = This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
