Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

On 14Jun2009 15:16, I wrote: | Is it possible to access the buffer? I see nothing in the docs. I've just found getvalue() in IOBase. Forget I said anything. It seems to be my day for that kind of post:-( -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ These are but a few examples

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

On 14Jun2009 12:33, Greg Ewing wrote: > Antoine Pitrou wrote: >> The original docstring for peek() says: >> >> ...we >> do at most one raw read to satisfy it. >> >> In that light, I'm not sure it's a bug > > It may be behaving according to the docs, but is that > behaviour useful?

Re: [Python-Dev] Distributed computing & sending the interpreter

> > Definitely the wrong list -- python-dev is for people working on the core > interpreter and libraries. comp.lang.python would be the standard place, > but you might also find some good advice on the new list concurrency-sig. Sorry for the list pollution, I will repost it there. Thanks, Jere

Re: [Python-Dev] Distributed computing & sending the interpreter

On Sat, Jun 13, 2009, Jeremy Cowles wrote: > > I apologize if this question is misplaced, I wasn't sure which list to > post it in. > > I'm working on a distributed computing project (PyMW and BOINC) where > we are sending Python scripts to client machines. Currently, we make > two very unlikely as

[Python-Dev] Distributed computing & sending the interpreter

Hi all, I apologize if this question is misplaced, I wasn't sure which list to post it in. I'm working on a distributed computing project (PyMW and BOINC) where we are sending Python scripts to client machines. Currently, we make two very unlikely assumptions: that Python 2.5 is installed and that

Re: [Python-Dev] Iterator version of contextlib.nested

Hagen Fürstenau wrote: > I guess this is much too late for 3.1, but could we then at least > un-deprecate "contextlib.nested" for now? As it is, you get a > DeprecationWarning for something like > > with contextlib.nested(*my_managers): > > without any good way to get rid of it. I actually almos

Re: [Python-Dev] ctime: I don't think that word means what you think it means.

Zooko Wilcox-O'Hearn wrote: 1. Add a "st_crtime" field which gets populated on filesystems (Windows, ZFS, Mac) which can do so. "crtime" looks rather too similar to "ctime" for my liking. People who think that the "c" in "ctime" means "creation" are still likely to confuse them. Why not give

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

Greg Ewing canterbury.ac.nz> writes: > > I think it would be more useful if the "at most one > raw read" part were dropped. That would give it the > kind of deterministic behaviour generally expected > when dealing with buffered streams. As I already told Nick: please propose an implementation s

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

Antoine Pitrou wrote: The original docstring for peek() says: ...we do at most one raw read to satisfy it. In that light, I'm not sure it's a bug It may be behaving according to the docs, but is that behaviour useful? Seems to me that if you're asking for n bytes, then it's b

Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER

Enough is enough guys. As entertaining as this thread has been, shouldn't we be focused on the 3.1 release? Don't feed the trolls. Ok so one wandered in, but nobody needed to respond and it can only get worse from here. Please just flag the offending address(es) for moderation and ask them poli

Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FOR THE F-35 JOINT STRIKE FIGHTER

Guido,     The reason why I use a code name is that it would be dangerous to reveal my true name to the world since there are those who are radical liberals who would like to think that there is no need for a U.S. military and that people such as myself should be eliminated.  Think of the U.S. m

[Python-Dev] ctime: I don't think that word means what you think it means.

The stat module uses the "st_ctime" slot to hold two kinds of values which are semantically different and which are frequently confused with one another. It chooses which kind of value to put in there based on platform -- Windows gets the file creation time and all other platforms get the "ctime"

Re: [Python-Dev] FINAL PROPULSION OPEN SOURCE ENGINE VARIANT FORTHE F-35 JOINT STRIKE FIGHTER

The other benefit of the military using open source software is that is can save the taxpayers money over the short and long term. For some projects it is a small percentage of the total cost. However, for others it can be significant portion of the cost, so don't discount its use or its benefit.

[Python-Dev] [RELEASED] Python 3.1 Release Candidate 2

On behalf of the Python development team, I'm happy to announce the second release candidate of Python 3.1. Python 3.1 focuses on the stabilization and optimization of the features and changes that Python 3.0 introduced. For example, the new I/O system has been rewritten in C for speed. File sys

Re: [Python-Dev] Iterator version of contextlib.nested

> 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. It seems to me that both passing callables which return managers

Re: [Python-Dev] Avoiding file descriptors leakage in subprocess.Popen()

On Fri, Jun 12, 2009 at 9:06 PM, Christian Heimes wrote: > How about a nice 'n shiny context wrapper for the pipe: I'll do this! Thank you for the suggestion! BTW, as this is a good way of avoiding the FD leakage, should this context wrapper for pipe() be in the stdlib? Regards, -- .Facu

Re: [Python-Dev] Status of 2.7 and 3.2

Eric Pruitt gmail.com> writes: > > I am in the process of implementing a > number of often requested features and proposed patches in the subprocess > module for my Google Summer of Code 2009 project. For information on > my progress, check out my blog located at http://subdev.blogspot.com/.

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

Frederick Reeve solace.info> writes: > > 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 a

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

Nick Coghlan gmail.com> writes: > > 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. How do you propose to implement this while staying compatible with 1) unseekable raw stream

Re: [Python-Dev] Status of 2.7 and 3.2

Lennart Regebro writes: > 2009/6/7 Stephen J. Turnbull : > > Python's 2.x/py3k division is a tour de force; I still can't believe > > my eyes that you've pulled it off. > > Well, It's not pulled off until Python 3 has surpassed Python 2 in > usage. I'm referring only to the management of th

Re: [Python-Dev] Status of 2.7 and 3.2

2009/6/7 Stephen J. Turnbull : > Python's 2.x/py3k division is a tour de force; I still can't believe > my eyes that you've pulled it off. Well, It's not pulled off until Python 3 has surpassed Python 2 in usage. That's still a long way away. I'm not familiar with the other examples except Zope 3,

Re: [Python-Dev] Status of 2.7 and 3.2

I am in the process of implementing a number of often requested features and proposed patches in the subprocess module for my Google Summer of Code 2009 project. For information on my progress, check out my blog located at * http://subdev.blogspot.com/* . Any comments a

Re: [Python-Dev] io.BufferedReader.peek() Behaviour in python3.1

Cameron Simpson wrote: > On 13Jun2009 12:24, Nick Coghlan wrote: > | 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 r