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
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 overfl
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 con
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
> value
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
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 incom
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 Py
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 b
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 ca
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 over
From the initial bugreport
(http://sourceforge.net/tracker/index.php?
func=detail&aid=1112549&group_id=5470&atid=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
> 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 functi
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
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
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).
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
Nick Coghlan wrote:
> 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) # wo
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/s
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
http://www
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 functionalit
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 f
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
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 see
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 s
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 rea
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
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
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() fun
[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 c
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
"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
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 ma
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
> f
submitted patch:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1530482&group_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
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
failed
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 s
[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_Rep
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 =
It checks for ifconfig, /sbin/ifconfig, and /usr/sbin/ifconfig (same
for arp). The problem is the os.pipe command doesn't hide these
issues. It doesn't cause the test to fail, but is still broken. The
test is presumably failing for the other reason I mentioned
(unixdll_getnode). Let me know if
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
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)
>>
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!
>
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 shou
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 becaus
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: arp:
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 t
-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 -
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 apply
Anthony Baxter <[EMAIL PROTECTED]> writes:
> On Friday 28 July 2006 15:32, Raymond Hettinger wrote:
>> I suggest that there be a third beta release and that we then wait
>> just a bit before going final.
>>
>> The bugs that were found and fixed in the first two beta releases
>> suggest that Py2.5
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.
>
> Lo
50 matches
Mail list logo
