Am 18.11.2005 um 02:16 schrieb Guido van Rossum:
On 11/17/05, Walter Dörwald [EMAIL PROTECTED] wrote:
Am 17.11.2005 um 22:03 schrieb Guido van Rossum:
On 11/17/05, Walter Dörwald [EMAIL PROTECTED] wrote:
[...]
Should they raise the same exception? Should this be fixed for 2.5?
I think
Guido van Rossum wrote:
On 11/17/05, Walter Dörwald [EMAIL PROTECTED] wrote:
Am 17.11.2005 um 22:03 schrieb Guido van Rossum:
On 11/17/05, Walter Dörwald [EMAIL PROTECTED] wrote:
Currently StringIO.StringIO and cStringIO.StringIO behave differently
when iterating a closed stream:
[...]
import StringIO, cStringIO
s = StringIO.StringIO()
s.truncate(-42)
Traceback (most recent call last):
File stdin, line 1, in ?
File /usr/local/lib/python2.4/StringIO.py, line 203, in truncate
raise IOError(EINVAL, Negative size not allowed)
IOError: [Errno 22] Negative size not
The behavior of libiberty's alloca() replacement might be interesting as well:
http://gcc.gnu.org/onlinedocs/libiberty/Functions.html#index-alloca-59
Regards,
Michael
On 11/18/05, Alex Martelli [EMAIL PROTECTED] wrote:
On Nov 17, 2005, at 5:00 PM, Thomas Lee wrote:
Portability may also be
Guido van Rossum wrote:
I hope there isn't anyone here who believes this patch would be a bad idea?
Not me, but the Iterator protocol docs may need a minor tweak. Currently they
say this:
The intention of the protocol is that once an iterator's next() method raises
StopIteration, it will
[Guido van Rossum]
I hope there isn't anyone here who believes this patch would be a
bad
idea?
[Nick Coglan]
Not me, but the Iterator protocol docs may need a minor tweak.
Currently
they
say this:
The intention of the protocol is that once an iterator's next()
method
raises
There is a public-domain implementation of alloca at
http://www.cs.purdue.edu/homes/apm/courses/BITSC461-fall03/listen-code/listen-1.0-dave/lsl_cpp/alloca.c
It would still fail on architectures that don't use a stack frame; other
than that, it seems like a reasonable fallback, if alloca is
On 11/18/05, Raymond Hettinger [EMAIL PROTECTED] wrote:
For Walter's original question, my preference is to change the behavior
of regular files to raise StopIteration when next() is called on an
iterator for a closed file.
I disagree. As long as there is a possibility that you might still
On 11/18/05, Walter Dörwald [EMAIL PROTECTED] wrote:
import StringIO, cStringIO
s = StringIO.StringIO()
s.truncate(-42)
Traceback (most recent call last):
File stdin, line 1, in ?
File /usr/local/lib/python2.4/StringIO.py, line 203, in truncate
raise IOError(EINVAL,
Guido van Rossum wrote:
On 11/18/05, Walter Dörwald [EMAIL PROTECTED] wrote:
import StringIO, cStringIO
s = StringIO.StringIO()
s.truncate(-42)
Traceback (most recent call last):
File stdin, line 1, in ?
File /usr/local/lib/python2.4/StringIO.py, line 203, in truncate
raise
Noam Raphael wrote:
I just wanted to add another use case: long messages. Consider those
lines from idlelib/run.py:133
msg = IDLE's subprocess can't connect to %s:%d. This may be due \
to your personal firewall configuration. It is safe to \
allow this
Folks, I'm off for a week with my wife's family (and one unlucky
turkey :-) in a place where I can't care about email. I will be back
here on Monday Nov 28.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Patch / Bug Summary
___
Patches : 379 open (+14) / 2968 closed ( +7) / 3347 total (+21)
Bugs: 910 open ( +6) / 5384 closed (+17) / 6294 total (+23)
RFE : 200 open ( +0) / 191 closed ( +2) / 391 total ( +2)
New / Reopened Patches
__
PythonD
13 matches
Mail list logo
