[Python-Dev] Iterator version of contextlib.nested
contextlib.nested has recently been deprecated on grounds of being unnecessary now that the with statement accepts multiple context managers. However, as has been mentioned before (http://mail.python.org/pipermail/python-dev/2009-May/089359.html), that doesn't cover the case of a variable number of context managers, i.e. with contextlib.nested(*list_of_managers) as list_of_results: or with contexlib.nested(*iterator_of_managers): It was suggested that in these use cases a custom context manager should be implemented. However, it seems that such an implementation would be an almost exact copy of the present code for "nested". I'm proposing to add an iterator version of "nested" to contextlib (possibly called "inested"), which takes an iterable of context managers instead of a variable number of parameters. The implementation could be taken over from the present "nested", only changing "def nested(*managers)" to "def inested(managers)". This has the advantage that an iterator can be passed to "inested", so that each context managers is created in the context of all previous ones, which was one of the reasons for introducing the multi-with statement in the first place. "contextlib.inested" would therefore be the generalization of the multi-with statement to a variable number of managers (and "contextlib.nested" would stay deprecated). - Hagen ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (06/05/09 - 06/12/09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2225 open (+39) / 15869 closed (+26) / 18094 total (+65) Open issues with patches: 882 Average duration of open issues: 652 days. Median duration of open issues: 402 days. Open Issues Breakdown open 2197 (+39) pending28 ( +0) Issues Created Or Reopened (68) ___ Issue with RotatingFileHandler logging handler on Windows06/08/09 CLOSED http://bugs.python.org/issue4749reopened r.david.murray add disable_nagle_algorithm to SocketServer.TCPServer06/08/09 http://bugs.python.org/issue6192reopened pitrou patch, patch, easy test_float fails on Windows 06/05/09 CLOSED http://bugs.python.org/issue6198reopened eric.smith path separator output ignores shell's path separator: / instead 06/05/09 http://bugs.python.org/issue6208created ThurnerRupert compilation error in std. lib. module shutil (Python 3.1rc1, pla 06/05/09 CLOSED http://bugs.python.org/issue6209created dpodbori Exception Chaining missing method for suppressing context06/05/09 http://bugs.python.org/issue6210created poke [Tutorial] Section 4.7.2 has a wrong description of an example 06/05/09 CLOSED http://bugs.python.org/issue6211created cofi patch piped input 06/05/09 CLOSED http://bugs.python.org/issue6212created rtmq Incremental encoder incompatibility between 2.x and py3k 06/05/09 http://bugs.python.org/issue6213created pitrou test__locale broken on trunk 06/05/09 CLOSED http://bugs.python.org/issue6214created pitrou Backport the IO lib to trunk 06/05/09 http://bugs.python.org/issue6215created pitrou patch Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32? 06/06/09 http://bugs.python.org/issue6216created tjreedy Add _io._TextIOWrapper.errors06/06/09 CLOSED http://bugs.python.org/issue6217created pjenvey patch Make io.BytesIO and io.StringIO picklable. 06/06/09 http://bugs.python.org/issue6218created alexandre.vassalotti patch, patch nested list value change 06/06/09 CLOSED http://bugs.python.org/issue6219created pushkarparanjpe typo: opne in "doanddont"06/06/09 CLOSED http://bugs.python.org/issue6220created cate Windows buildbot failure in test_winreg 06/06/09 CLOSED http://bugs.python.org/issue6221created pitrou 2to3 except fixer failed in certain case 06/06/09 CLOSED http://bugs.python.org/issue6222created bhy Make _PyUnicode_AsString as public API 06/06/09 CLOSED http://bugs.python.org/issue6223created bhy
[Python-Dev] Avoiding file descriptors leakage in subprocess.Popen()
In a long lived process at work, we started leaking file descriptors. The problem were that subprocess.Popen._execute_child() method creates two files descriptors through a call to os.pipe(), and after some work it closes them. But an os.read() on the descriptor was interrupted (EINTR), so an exception was raised, and the descriptors were not closed... leakage! This problem is easy to fix (I have a patch that fixes it, all tests pass ok, see http://bugs.python.org/issue6274). So, why this mail? I just think that the fix is ugly... it's not elegant. It has the following structure: errpipe_read, errpipe_write = os.pipe() try: try: . . . . . . finally: os.close(errpipe_write) . . . finally: os.close(errpipe_read) I just don't like a huge try/finally... but as FDs are just ints, do you think is there a better way to handle it? Thank you!! Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
TO ALL, I AM HAPPY TO SAY THAT I AM NOW IN THE PROCESS OF DEVELOPING A WEBSITE FOR THE STATED PURPOSE OF COMBINING SOME OF THE BEST MINDS IN THE WORLD. THIS PROJECT WILL BE A MEANS TO DEVELOP THE FIRST AND ONLY COMPLETELY OPEN SOURCE VARIANT OF THE PROPULSION ENGINE FOR THE F-35 JOINT STRIKE FIGHTER. WHICH MEANS THAT EVERYTHING ABOUT THE DESIGN, DEVELOPMENT, AND CONSTRUCTION OF THE ENGINE WILL BE COMPLETELY AVAILABLE TO THE PUBLIC AND TO ANY ENGINE MANUFACTURE FREE OF ANY REQUIREMENTS. THIS ENGINE WILL BE CALLED THE PHOENIX NexT F-200 ENGINE. THIS ENGINE WILL ALSO BE A POTENTIAL THIRD AND FINAL ALTERNATIVE ENGINE FOR THE JOINT STRIKE FIGHTER. THIS ENGINE WILL BE STATED AS BEING A COMPETITOR WITH BOTH THE F-135 AND THE F-136 ENGINE, WHICH ARE PROVIDED BY BOTH PRATT-WHITNEY AND GENERAL ELECTRIC/ ROLLS ROYCE. THIS ENGINE WILL UTILIZE PYTHON FOR THE MAJOR PORTION OF THE SIMULATION, RESEARCH AND DEVELOPMENT STAGES FOR THE DEVELOPMENT OF THE ENGINE. THE CONSTRUCTION OF THE MATHEMATICAL PROCESSING OF THE REQUIRED NONLINEAR CONTROLS WILL BE BASED ON A SPECIALIZED VERSION OF GROUP THEORY FOR THE DESIGN AND CONSTRUCTION OF THE NONLINEAR CONTROL SYSTEMS. THE PURPOSE OF THE DEVELOPMENT OF THE ENGINE WILL BE TO CONSTRUCT AN ENGINE FOR THE F-35 THAT WILL BE AS RELIABLE AND CAPABLE AS THE F-135 AND THE F-136. HOWEVER, THE PHOENIX NexT ENGINE WILL ALSO BE STATED AS BEING ONLY AROUND $20,000 TO $110,000 DOLLARS TO BEING PURCHASED BY AN OPERATOR OF THE F-35, WHICH WILL BE AN INSIGNIFICANT COST COMPARED TO THE COST OF BOTH THE F-135 AND THE F-136 ENGINE (10 MILLION DOLLARS PER UNIT). HOW MANY OUT THERE WANT TO HELP IN THIS ENDEAVOR ? I BELIEVE THAT WE ALL CAN SUCCEED WHERE BOTH PRATT-WHITNEY AND GE/ROLLS ROYCE HAVE FAILED TO DEVELOP AN INEXPENSIVE AND RELIABLE ENGINE FOR THE F-35. THANKS, W108DAB ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
On 13 Jun 2009, at 00:01, OMEGA RED wrote: DEVELOP THE FIRST AND ONLY COMPLETELY OPEN SOURCE VARIANT OF THE PROPULSION ENGINE FOR THE F-35 JOINT STRIKE FIGHTER You're unlikely to find many people who want to help use open-source to facilitate murder. HOW MANY OUT THERE WANT TO HELP IN THIS ENDEAVOR ? Nobody here. You're off topic, this list is for development of Python, not pet projects. Matt ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
On Fri, Jun 12, 2009 at 4:53 PM, Matthew Wilkes wrote: > > On 13 Jun 2009, at 00:01, OMEGA RED wrote: > >> DEVELOP THE FIRST AND ONLY COMPLETELY OPEN SOURCE VARIANT OF THE >> PROPULSION ENGINE FOR THE F-35 JOINT STRIKE FIGHTER > > You're unlikely to find many people who want to help use open-source to > facilitate murder. That's a rather presumptuous statement. Despite the poster's use of SHOUTING I don't see a reason to tell them they should use proprietary software just because you disagree with their politics. (Hey, I disagree with Eric Raymond's *and* Richard Stallman's politics. :-) >> HOW MANY OUT THERE WANT TO HELP IN THIS ENDEAVOR ? > > Nobody here. You're off topic, this list is for development of Python, not > pet projects. True. Comp.lang.python might be a better place. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
2009/6/12 Guido van Rossum : > On Fri, Jun 12, 2009 at 4:53 PM, Matthew > Wilkes wrote: >> On 13 Jun 2009, at 00:01, OMEGA RED wrote: >>> HOW MANY OUT THERE WANT TO HELP IN THIS ENDEAVOR ? >> >> Nobody here. You're off topic, this list is for development of Python, not >> pet projects. > > True. Comp.lang.python might be a better place. Actually, I think the Python community might be better off if he went to comp.lang.perl. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER
On 13 Jun 2009, at 01:00, Guido van Rossum wrote: That's a rather presumptuous statement. Despite the poster's use of SHOUTING I don't see a reason to tell them they should use proprietary software just because you disagree with their politics Oh, I didn't mean they should use proprietary software, just that in my experience the kind of people who are active in open source are quite anti-war, green, etc. There are notable exceptions, but I know people who worry that their work will have military applications, and who turn down projects because of it. You're more likely to get people who are interested in aviation with some programming background (universities do teach coding to engineers, afterall), than the other way around. Matt ___ Python-Dev mailing list [email protected] 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()
Facundo Batista wrote: > I just don't like a huge try/finally... but as FDs are just ints, do > you think is there a better way to handle it? How about a nice 'n shiny context wrapper for the pipe: import os class Pipe(object): def __enter__(self): self.read, self.write = os.pipe() return self.read, self.write def __exit__(self, *args): try: os.close(self.read) finally: # make sure that write is closed even if # self.read can't be closed os.close(self.write) with Pipe() as (read, write): print read, write Christian PS and nit pick: File descriptor are opaque resource handlers which just happened to be ints. They should be treated as magic cookies. ___ Python-Dev mailing list [email protected] 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()
Facundo Batista wrote: > I just don't like a huge try/finally... but as FDs are just ints, do > you think is there a better way to handle it? How about a nice 'n shiny context wrapper for the pipe: import os class Pipe(object): def __enter__(self): self.read, self.write = os.pipe() return self.read, self.write def __exit__(self, *args): try: os.close(self.read) finally: # make sure that write is closed even if # self.read can't be closed os.close(self.write) with Pipe() as (read, write): print read, write Christian PS and nit pick: File descriptor are opaque resource handlers which just happened to be ints. They should be treated as magic cookies. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FORTHE F-35 JOINT STRIKE FIGHTER
[Matthew Wilkes] Oh, I didn't mean they should use proprietary software, just that in my experience the kind of people who are active in open source are quite anti-war, green, etc. There are notable exceptions, but I know people who worry that their work will have military applications, and who turn down projects because of it. I question the whole notion of using open source in military weapons. It seems like a rather basic violation of operational security. Perhaps your enemies will exploit your bugs instead of nicely reporting them and submitting patches on SourceForge ;-) Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FORTHE F-35 JOINT STRIKE FIGHTER
On Fri, Jun 12, 2009 at 5:17 PM, Raymond Hettinger wrote: > > [Matthew Wilkes] >> >> Oh, I didn't mean they should use proprietary software, just that in my >> experience the kind of people who are active in open source are quite >> anti-war, green, etc. There are notable exceptions, but I know people who >> worry that their work will have military applications, and who turn down >> projects because of it. > > I question the whole notion of using open source in military weapons. > It seems like a rather basic violation of operational security. Perhaps > your enemies will exploit your bugs instead of nicely reporting them > and submitting patches on SourceForge ;-) Eric Raymond would argue that it's probably the other way around -- proprietary software doesn't have enough eyeballs to make it safe. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] io.BufferedReader.peek() Behaviour in python3.1
Greetings, I feel the need to point out I made a mistake. When I wrote my last email I said the behavior had changed python3-3.1. This seems not to be the case.. I had made that assumption because I had written code based on the looking at the code in _pyio.py as well as the python3 documentation (http://docs.python.org/3.0/library/io.html#io.BufferedReader) which seems to be wrong on that point or I miss understand. Anyway I'm sorry about that. The other point still stands though. I would like to see peek changed. I am willing to write and submit changes but don't want to unless others agree this is a good idea. So I put forth the implementation at the bottom of this email. If its bad or you don't see the point I may try to clarify but if nobody things its good, please just tell me I'm waisting your time, and I will go away. I also apologize my last email was so long. peek(n): If n is less than 0, None, or not set; return buffer contents with out advancing stream position. If the buffer is empty read a full chunk and return the buffer. Otherwise return exactly n bytes up to _chunk size_(not contents) with out advancing the stream position. If the buffer contents is less than n, buffer an additional chunk from the "raw" stream before hand. If EOF is encountered during any raw read then return as much as we can up to n. (maybe I should write that in code form??) Thanks Frederick Reeve ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Iterator version of contextlib.nested
Hagen Fürstenau wrote: > I'm proposing to add an iterator version of "nested" to contextlib > (possibly called "inested"), which takes an iterable of context managers > instead of a variable number of parameters. The implementation could be > taken over from the present "nested", only changing "def > nested(*managers)" to "def inested(managers)". > > This has the advantage that an iterator can be passed to "inested", so > that each context managers is created in the context of all previous > ones, which was one of the reasons for introducing the multi-with > statement in the first place. "contextlib.inested" would therefore be > the generalization of the multi-with statement to a variable number of > managers (and "contextlib.nested" would stay deprecated). The semantic change actually needed to make nested() more equivalent to the multi-with statement is for it to accept zero-argument callables that create context managers as arguments rather than pre-created context managers. Rather than changing the name of the function, this could be done by inspecting the first argument for an "__enter__" method. If it has one, use the old semantics (and issue a DeprecationWarning as in 3.1). Otherwise, use the proposed new semantics. However, the semantic equivalence still won't be complete as nested() currently has no way of matching the multi-with behaviour of allowing outer context managers to suppress exceptions raised by the constructors or __enter__ methods of inner context managers. Attempting to do so will result in a RuntimeError as the contextlib.contextmanager wrapper complains that the generator implementing nested() didn't yield. The further enhancement needed to address that would be to tweak nested() to raise a custom exception in that case (e.g. ContextSkipped) and provide an "allowskip" context manager that just catches and suppresses that specific exception: i.e. @contextmanager def allowskip(): try: yield except ContextSkipped: pass with allowskip(), nested(*cm_factories): # Do something I suggest putting an RFE on the tracker for this. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FORTHE F-35 JOINT STRIKE FIGHTER
>> I question the whole notion of using open source in military weapons. >> It seems like a rather basic violation of operational security. Perhaps >> your enemies will exploit your bugs instead of nicely reporting them >> and submitting patches on SourceForge ;-) > > Eric Raymond would argue that it's probably the other way around -- > proprietary software doesn't have enough eyeballs to make it safe. :-) > I guess in some cases it wouldn't matter if it were open source: http://online.wsj.com/article/SB124027491029837401.html I'm not sure of the seriousness (or mental stability) of Mr. "OMEGA RED", but I definitely got a chuckle from this :) - Phillip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FORTHE F-35 JOINT STRIKE FIGHTER
Raymond Hettinger wrote: > > [Matthew Wilkes] >> Oh, I didn't mean they should use proprietary software, just that in >> my experience the kind of people who are active in open source are >> quite anti-war, green, etc. There are notable exceptions, but I know >> people who worry that their work will have military applications, and >> who turn down projects because of it. > > I question the whole notion of using open source in military weapons. > It seems like a rather basic violation of operational security. Perhaps > your enemies will exploit your bugs instead of nicely reporting them > and submitting patches on SourceForge ;-) As Guido said, even the military are aware that there are major problems with the idea of security through obscurity. Plus most defence forces around the world are just as interested in saving a few bucks on software costs as any other organisation, particularly if they can reduce their reliance on a foreign software vendor in the process. As to the existence of open source developers that are willing to work with the military... as Matthew said, while they may not be particularly common, I can definitely say that they're around ;) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FORTHE F-35 JOINT STRIKE FIGHTER
On Jun 12, 2009, at 5:17 PM, Raymond Hettinger wrote: [Matthew Wilkes] Oh, I didn't mean they should use proprietary software, just that in my experience the kind of people who are active in open source are quite anti-war, green, etc. There are notable exceptions, but I know people who worry that their work will have military applications, and who turn down projects because of it. I question the whole notion of using open source in military weapons. It seems like a rather basic violation of operational security. Perhaps your enemies will exploit your bugs instead of nicely reporting them and submitting patches on SourceForge ;-) FYI Python (Jython) is already used in production of the F-35. There was a talk @ PyCon '08 about it: http://us.pycon.org/2008/conference/schedule/event/27/ http://www.youtube.com/watch?v=zgE55z_RNgQ -- Philip Jenvey ___ Python-Dev mailing list [email protected] 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
Frederick Reeve wrote:
> The other point still stands though. I would like to see peek
> changed. I am willing to write and submit changes but don't want to
> unless others agree this is a good idea. So I put forth the
> implementation at the bottom of this email. If its bad or you don't
> see the point I may try to clarify but if nobody things its good,
> please just tell me I'm waisting your time, and I will go away. I
> also apologize my last email was so long.
>
> peek(n): If n is less than 0, None, or not set; return buffer
> contents with out advancing stream position. If the buffer is empty
> read a full chunk and return the buffer. Otherwise return exactly n
> bytes up to _chunk size_(not contents) with out advancing the stream
> position. If the buffer contents is less than n, buffer an
> additional chunk from the "raw" stream before hand. If EOF is
> encountered during any raw read then return as much as we can up to
> n. (maybe I should write that in code form??)
I would phrase this suggestion as users having a reasonable expectation
that the following invariant should hold for a buffered stream:
f.peek(n) == f.read(n)
Since the latter method will perform as many reads of the underlying
stream as necessary to reach the requested number of bytes (or EOF),
then so should the former.
However, the default value for n for peek() should remain at 1 to remain
consistent with the current documented behaviour.
If this invariant was implemented, I would also suggest adding a "peek1"
method to parallel "read1".
Note that the current behaviour I get from Python 3.1 is for it to
return the *entire* buffer, no matter what number I pass to it:
(current Py3k head)
>>> f = open('setup.py', 'rb')
>>> len(f.peek(10))
4096
>>> len(f.peek(1))
4096
>>> len(f.peek(4095))
4096
>>> len(f.peek(10095))
4096
That's an outright bug - I've promoted an existing issue about this [1]
to a release blocker and sent it to Benjamin to have another look at.
Cheers,
Nick.
[1] http://bugs.python.org/issue5811
--
Nick Coghlan | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
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
On 13Jun2009 12:24, Nick Coghlan wrote: | Frederick Reeve wrote: | > The other point still stands though. I would like to see peek | > changed. I am willing to write and submit changes but don't want to | > unless others agree this is a good idea. So I put forth the | > implementation at the bottom of this email. If its bad or you don't | > see the point I may try to clarify but if nobody things its good, | > please just tell me I'm waisting your time, and I will go away. I | > also apologize my last email was so long. | > | > peek(n): If n is less than 0, None, or not set; return buffer | > contents with out advancing stream position. If the buffer is empty | > read a full chunk and return the buffer. Otherwise return exactly n | > bytes up to _chunk size_(not contents) with out advancing the stream | > position. If the buffer contents is less than n, buffer an | > additional chunk from the "raw" stream before hand. If EOF is | > encountered during any raw read then return as much as we can up to | > n. (maybe I should write that in code form??) | | I would phrase this suggestion as users having a reasonable expectation | that the following invariant should hold for a buffered stream: | | f.peek(n) == f.read(n) | | Since the latter method will perform as many reads of the underlying | stream as necessary to reach the requested number of bytes (or EOF), | then so should the former. I disagree. If that were that case, why have peek() at all? I realise that it doesn't move the logical position, but it does mean that peek(huge_number) imposes a requirement to grow the stream buffer arbitrarily. A peek that does at most one raw read has the advantage that it can pick up data outside the buffer but lurking in the OS buffer, yet to be obtained. Those data are free, if they're present. (Of course, if they're absent peek() wil still block). Since (if the OS buffer is also empty) even a peek(1) can block, maybe we should canvas peek()'s common use cases. Naively (never having used peek()), my own desire would normally be for a peek(n, block=False) a bit like Queue.get(). Then I could be sure not to block if I wanted to avoid it, even on a blocking stream, yet still obtain unread buffered data if present. So: what do people use peek() for, mostly? Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ We're in the business of putting goo on a substrate. - overhead by WIRED at the Intelligent Printing conference Oct2006 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
