Didn't you know that you signed in to run arbitrary viruses, worms, and
trojan horses when you added your machine to the buildbot infrastructure
:-? You just haven't seen buildbot erasing your hard disk and filling
your coffee machine with tea, yet.
VMware Server is free. Run buildbots in a
On 7/27/06, A.M. Kuchling [EMAIL PROTECTED] wrote:
On Thu, Jul 27, 2006 at 05:40:57PM +0200, Georg Brandl wrote:
The UUID test suite, which wasn't run by regrtest.py until now, is
now failing on some buildbots (and my machine). This should be fixed
before releasing something.
Looking at
Hi,
There is an oversight in the design of __index__() that only just
surfaced :-( It is responsible for the following behavior, on a 32-bit
machine with = 2GB of RAM:
s = 'x' * (2**100) # works!
len(s)
2147483647
This is because PySequence_Repeat(v, w) works by applying
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 28, 2006, at 1:39 AM, Anthony Baxter wrote:
I've been thinking the same thing, too. A quick chat to Neal says that
he also agrees.
There's still a lot more bugs popping up than I'm really comfortable
with. I guess this is inevitable -
i have a problem with pydoc in rpyc. i wanted help(obj), where obj
is a NetProxy object, to work as if it were local.
i followed the code starting from site.help to pydoc.doc, which is the
ultimate function that generates and prints the text. i expected there
would be some function in the middle
I just tried building and testing 2.5 on a Solaris 10 box at work. The uuid
test failed with
sh: ifconfig: not found
sh: ifconfig: not found
sh: ifconfig: not found
sh: arp: not found
sh: ifconfig: not found
sh: ifconfig: not found
sh: ifconfig: not found
sh:
Armin Rigo wrote:
Hi,
There is an oversight in the design of __index__() that only just
surfaced :-( It is responsible for the following behavior, on a 32-bit
machine with = 2GB of RAM:
s = 'x' * (2**100) # works!
len(s)
2147483647
This is because
On 7/28/06, Neal Norwitz [EMAIL PROTECTED] wrote:
On 7/27/06, A.M. Kuchling [EMAIL PROTECTED] wrote: On Thu, Jul 27, 2006 at 05:40:57PM +0200, Georg Brandl wrote: The UUID test suite, which wasn't run by regrtest.py until now, is
now failing on some buildbots (and my machine). This should be
David Hopwood [EMAIL PROTECTED] writes:
Armin Rigo wrote:
Hi,
There is an oversight in the design of __index__() that only just
surfaced :-( It is responsible for the following behavior, on a 32-bit
machine with = 2GB of RAM:
s = 'x' * (2**100) # works!
len(s)
David Hopwood wrote:
Armin Rigo wrote:
Hi,
There is an oversight in the design of __index__() that only just
surfaced :-( It is responsible for the following behavior, on a 32-bit
machine with = 2GB of RAM:
s = 'x' * (2**100) # works!
len(s)
2147483647
This is
At 07:33 AM 7/28/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I'm willing to write code that makes it PEP 302 compliant, if the release
manager will bless such an addition. But if that's not acceptable, then
somebody needs to produce the necessary documentation updates or revert
Michael Hudson wrote:
David Hopwood [EMAIL PROTECTED] writes:
Armin Rigo wrote:
Hi,
There is an oversight in the design of __index__() that only just
surfaced :-( It is responsible for the following behavior, on a 32-bit
machine with = 2GB of RAM:
s = 'x' * (2**100) # works!
[Armin Rigo]
There is an oversight in the design of __index__() that only just
surfaced :-( It is responsible for the following behavior, on a 32-bit
machine with = 2GB of RAM:
s = 'x' * (2**100) # works!
len(s)
2147483647
This is because PySequence_Repeat(v, w) works
On 7/28/06, Michael Hudson [EMAIL PROTECTED] wrote:
Anthony Baxter [EMAIL PROTECTED] writes:
Does anyone disagree with making the next release beta3?
It seems like a good idea to me. I guess this will mean the final
release will be pushed back a bit?
Anthony and I talked about still
Argh.
I also find it a bug.
I also feel responsible because I reviewed the patch. :-(
In my recollection I tried to avoid this exact behavior. I wanted
__index__() to just return the unclipped int or long value, but have a
C API that clipped it for use in slice operations. It looks like I
submitted patch:
https://sourceforge.net/tracker/?func=detailatid=305470aid=1530482group_id=5470
-tomer
-- Forwarded message --
From: tomer filiba [EMAIL PROTECTED]
Date: Jul 28, 2006 3:35 PM
Subject: patching pydoc?
To: python-dev@python.org
i have a problem with pydoc in
Tim Peters wrote:
OTOH, in the long discussion about PEP 357, I'm not sure anyone except
Travis was clear on whether nb_index was meant to apply only to
sequence /slicing/ or was meant to apply everywhere an object gets
used in an index-like context. Clipping makes sense only for the
former,
Nick Coghlan wrote:
Tim Peters wrote:
OTOH, in the long discussion about PEP 357, I'm not sure anyone except
Travis was clear on whether nb_index was meant to apply only to
sequence /slicing/ or was meant to apply everywhere an object gets
used in an index-like context. Clipping makes sense
tomer filiba [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
...
therefore, i would like to split this behavior into two parts:
* render_doc - a function that returns the document text
* doc - a function that calls render_doc and sends it to the pager
this way no existing code
On 7/28/06, Nick Coghlan [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Tim Peters wrote:
OTOH, in the long discussion about PEP 357, I'm not sure anyone except
Travis was clear on whether nb_index was meant to apply only to
sequence /slicing/ or was meant to apply everywhere an object gets
[Tim]
...
This is a mess :-)
[Nick Coghlan]
I've been trawling through the code a bit, and I don't think it's as bad as
all that.
[also Nick, but older wiser ;-)]
Damn, it really is a mess. . . nb_index returns the Pyssize_t directly,
Bingo. It's a /conceptual/ mess. Best I can make
Armin Rigo wrote:
In the same spirit, maybe it could be slightly re-oriented towards a
dumper/loader for more than config files; for example, it could provide
a safe inverse of repr() for common built-in types
New version of miniconf (version 1.2.0) is out [1][2], including a
unrepr()
Sylvain Fourmanoit wrote:
Armin Rigo wrote:
In the same spirit, maybe it could be slightly re-oriented towards a
dumper/loader for more than config files; for example, it could provide
a safe inverse of repr() for common built-in types
New version of miniconf (version 1.2.0) is
Neal Norwitz wrote:
Anthony and I talked about still having b3 on Aug 1. rc1 around Aug
17-18 (just before the Google sprint which Martin, Jeremy and I will
be attending). Final around 24-29. We didn't discuss with Martin
yet, so these dates are quite tentative.
If it doesn't muck-up your
On Friday 28 July 2006 00:49, Neal Norwitz wrote:
Based on this comment, is it really acceptable to just document a
behaviour change? ISTM there should really only be 2 choices: fix
2.5 properly or revert the change. This seemed to be Armin's
position.
I agree those are the only
It seems that the pre-2.5 struct module has some additional
undocumented behavior[1] that didn't percolate into the new version:
http://python.org/sf/1530559
Python 2.4 and previous will coerce floats to integers when necessary
as such without any kind of complaint:
$ python2.4 -c import
At 04:07 PM 7/28/2006 -0400, Fred L. Drake, Jr. wrote:
On Friday 28 July 2006 00:49, Neal Norwitz wrote:
Based on this comment, is it really acceptable to just document a
behaviour change? ISTM there should really only be 2 choices: fix
2.5 properly or revert the change. This seemed to
Neal Norwitz wrote:
Anthony and I talked about still having b3 on Aug 1. rc1 around Aug
17-18 (just before the Google sprint which Martin, Jeremy and I will
be attending). Final around 24-29. We didn't discuss with Martin
yet, so these dates are quite tentative.
That doesn't work for me.
Phillip J. Eby wrote:
The issue is that a proper fix that caches existence requires adding new
types to import.c and thus might appear to be more of a feature. I was
therefore reluctant to embark upon the work without some assurance that it
wouldn't be rejected as adding a last-minute
Hello all,
Sourceforge is being anal and won't let me log in.
Attached is a patch for the shutil test, which would pickup bug
[1525866] Bug in shutil.copytree on Windows.
It passes against a bug-fixed shutil [1] on my XP box, and fails on an
un-fixed one.
It only tests basic functionality
So I accidentally discovered the other day that httplib does not handle
a particular type of mangled HTTP response very well. In particular, it
tends to blow up with an undocumented ValueError when the server screws
up chunked encoding. I'm not the first to discover this, either: see
On Wednesday 26 July 2006 13:17, Terry Reedy wrote:
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Currently, we have two running tracker demos online:
Roundup:
http://efod.se/python-tracker/
Jira:
http://jira.python.atlassian.com/secure/Dashboard.jspa
At 10:55 PM 7/28/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
The issue is that a proper fix that caches existence requires adding new
types to import.c and thus might appear to be more of a feature. I was
therefore reluctant to embark upon the work without some assurance that
Travis Oliphant wrote:
I say it's a bug that should be fixed. Don't clear the error, raise it.
Several people have said this, but I don't think it can work.
If you raise an OverflowError in __index__, the slicing code cannot know
whether this meant as overflow or underflow (in a signed sense).
On Tue, 25 Jul 2006, Greg Ward wrote:
[...]
Where I'm getting hung up is how far to test this stuff.
Stop when you run out of time ;-)
I have
discovered other hypothetical cases of bad chunking that cause httplib
to go into an infinite loop or block forever on socket.readline().
Should we
tomer filiba wrote:
i have a problem with pydoc in rpyc. i wanted help(obj), where obj
is a NetProxy object, to work as if it were local.
i followed the code starting from site.help to pydoc.doc, which is the
ultimate function that generates and prints the text. i expected there
would be
Giving the amount of hair-tearing over uuid and __index__, this seems like
an especially bad day to ask for a new-feature variance in a time of
feature freeze ;-).
yeah, i guess so.
* Would making pager() a parameter of doc() make sense?
not at all.
* I presume you gain the new
From the initial bugreport
(http://sourceforge.net/tracker/index.php?
func=detailaid=1112549group_id=5470atid=105470)
Various parts of cgi.FieldStorage call its
read_lines_to_outerboundary, read_lines and
skip_lines methods. These methods use the
readline method of the file object that
Martin v. Löwis wrote:
Travis Oliphant wrote:
I say it's a bug that should be fixed. Don't clear the error, raise it.
Several people have said this, but I don't think it can work.
If you raise an OverflowError in __index__, the slicing code cannot know
whether this meant as overflow or
I'm looking for a way of modifying the compiler to eliminate any loops and recursion from code. It's for a high speed data processing application. The alternative is a custom language that is little more than gloryfied assembly. I'd like to be able to use everything else around Python, but we
On 7/28/06, Charles Vaughn [EMAIL PROTECTED] wrote:
I'm looking for a way of modifying the compiler to eliminate any loops and recursion from code. It's for a high speed data processing application. The alternative is a custom language that is little more than gloryfied assembly. I'd like to be
Armin Rigo wrote:
This is because PySequence_Repeat(v, w) works by applying w.__index__ in
order to call v-sq_repeat.
Why does it do that? Shouldn't __index__ only be used for
numbers which are going to be used as an index?
However, __index__ is defined to clip the
result to fit in a
Tim Peters wrote:
So, e.g., plain a[i] shouldn't use __index__ either if i is already
int or long. I don't see any justification for invoking nb_index in
sequence_repeat(), although if someone thinks it should, then as for
plain indexing it certainly shouldn't invoke nb_index if the incoming
Guido van Rossum wrote:
In my recollection I tried to avoid this exact behavior. I wanted
__index__() to just return the unclipped int or long value, but have a
C API that clipped it for use in slice operations.
So is there still a chance to fix it?
--
Greg
On 7/28/06, Bob Ippolito [EMAIL PROTECTED] wrote:
http://python.org/sf/1530559
[1] The pre-2.5 behavior should really be considered a bug, the
documentation says Return a string containing the values v1, v2, ...
packed according to the given format. The arguments must match the
values
Michael Urman wrote:
The fact that
round returns a float rather than an int, while intentional, does not
feature prominently in one's mine when the first version yielded the
expected results.
As an aside, does anyone else think that it would be
useful to have a builtin which rounds and
Martin v. Löwis wrote:
Travis Oliphant wrote:
I say it's a bug that should be fixed. Don't clear the error, raise it.
Several people have said this, but I don't think it can work.
If you raise an OverflowError in __index__, the slicing code cannot know
whether this meant as overflow or
Sylvain Fourmanoit wrote:
Armin Rigo wrote:
If it goes in that direction, I'd suggest to rename the module to give
it a name closer to existing persistence-related modules already in the
stdlib.
I am not especially fond of the current miniconf name either; I didn't
find something more
48 matches
Mail list logo
