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
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
>>> import StringIO, cStringIO
>>> s = StringIO.StringIO()
>>> s.truncate(-42)
Traceback (most recent call last):
File "", 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 si
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 al
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
> S
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 otherw
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 "", line 1, in ?
>File "/usr/local/lib/python2.4/StringIO.py", line 203, in truncate
> raise IOError
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 "", line 1, in ?
>> File "/usr/local/lib/python2.4/StringIO.py", line 203, in
Paul Svensson wrote:
> On Fri, 18 Nov 2005, Walter Dörwald wrote:
>
>> BTW, isatty() has a similar problem:
>>
>> >>> import StringIO, cStringIO
>> >>> s = StringIO.StringIO()
>> >>> s.close()
>> >>> s.isatty()
>> Traceback (most recent call last):
>> File "", line 1, in ?
>> File "/usr/local
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 "\
> "a
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
Pytho
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 D
14 matches
Mail list logo