Collin Winter wrote:
> Is it intentional that Python 2.5 is (currently) shipping with
> distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3)
> shipped with distutils 2.4.1? Judging from my own tests, distutils
> 2.4.1 fixed several bugs that some of my test suites depend on (the
> fi
Tim Peters wrote:
> Today I noticed this happened when the buildbot started to run tests,
> and I'm 100% sure it's due to this code in
> Tools/buildbot/kill_python.c
Didn't you know that you signed in to run arbitrary viruses, worms, and
trojan horses when you added your machine to the buildbot i
What is the behaviour that was added which broke compliance? What is
the benefit of the behaviour?
>From your description of fixing the problem, it seems there's some
risk invovled as it's modiyfing import.c, plus adding new features.
What is your recommendation?
n
--
On 7/26/06, Phillip J. Eby
On 7/26/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Today I noticed this happened when the buildbot started to run tests,
> and I'm 100% sure it's due to this code in
> Tools/buildbot/kill_python.c (the buildbot log files showed that
> kill_python.c killed /some/ Python process, and the Python ru
[This message is cc:d to the e-lang list, but please take any replies to
[EMAIL PROTECTED]
Brett Cannon wrote:
> On 7/19/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
>
>> OMG!!! Is all i can say at the moment. Very excited.
This is very encouraging. Thanks to ?!ng, Michael Chermside and others f
Is it intentional that Python 2.5 is (currently) shipping with
distutils 2.4.0, while Python 2.4 (at least 2.4.1, 2.4.2 and 2.4.3)
shipped with distutils 2.4.1? Judging from my own tests, distutils
2.4.1 fixed several bugs that some of my test suites depend on (the
fixes, not the bugs ; ).
Thanks,
Patch / Bug Summary
___
Patches : 401 open ( +3) / 3342 closed ( +8) / 3743 total (+11)
Bugs: 896 open ( -8) / 6035 closed (+24) / 6931 total (+16)
RFE : 224 open ( +2) / 233 closed ( +2) / 457 total ( +4)
New / Reopened Patches
__
pkgutil.w
Hello.
I noticed mbcs codec still has problem when calls StreamReader.
Can anyone commit the patch "fix.patch version2" on
http://python.org/sf/1455898 ?
# Very sorry about this... I thought I checked this, but I definitely looked
at something
# wrong.
__
Hi, after speaking with Neal off-list about writing tests for the
pkgutil module, we agreed it would be a good idea to start a page on
http://wiki.python.org/moin/ stating any tests for the standard
library that either,
a) need to be written
b) can be improved
I've started the page http://wiki.py
Rarely I'll be running the Python tests in my sandbox from a DOS box,
and the test run will just end. Like so:
C:\Code\python\PCbuild>python -E -tt ../lib/test/regrtest.py -uall -rw
test_softspace
test_codecmaps_kr
...
test_float
test_userdict
C:\Code\python\PCbuild>
No indication of success o
Here's the draft for the second half of June. As always, comments and
corrections are greatly appreciated.
=
Announcements
=
---
Python 2.5 schedule
---
A number of bugs are being squashed as Python 2.5 moves towards its
next release. Se
On Jul 26, 2006, at 3:18 PM, John J Lee wrote:
> On Wed, 26 Jul 2006, Phillip J. Eby wrote:
> [...]
>> Actually, I would see more reason to include JSON in the standard
>> library,
>> since it's at least something approaching an internet protocol
>> these days.
>
> +1
If there's a consensus
On Wed, 26 Jul 2006, Phillip J. Eby wrote:
[...]
> Actually, I would see more reason to include JSON in the standard library,
> since it's at least something approaching an internet protocol these days.
+1
John
___
Python-Dev mailing list
Python-Dev@p
At 05:43 PM 7/26/2006 -0400, Sylvain Fourmanoit wrote:
> > The loading code could also be made a lot faster by using a dictionary
> > mapping AST node types to functions, instead of doing string
> > manipulation for each node. Each function could take 'pedantic' as a
> > parameter, which would eli
> It looks like it's trivial to fix; the code uses a strange and
> unnecessary complication of creating nested classes and nested
> singleton instances thereof. Getting rid of the singletons to create a
> new instance for each dump/load call would suffice to make the
> implementation re-entran
> miniconf, OTOH, appears to have an interface compatible with capability
> security (I have not checked that the compiler.ast module used in its
> implementation is safe.)
I woudn't be 100% sure either (obviously, I didn't write this nice piece
of code, let alone the underlying parser), but I re
At 07:47 PM 7/26/2006 +0100, David Hopwood wrote:
>Sylvain Fourmanoit wrote:
> > I wrote a data persistence module called miniconf, aimed at making
> > easy to create and safely retrieve configuration info from external,
> > human-readable sources using Python syntax. I feel it would eventually
> >
Sylvain Fourmanoit wrote:
> I wrote a data persistence module called miniconf, aimed at making
> easy to create and safely retrieve configuration info from external,
> human-readable sources using Python syntax. I feel it would eventually
> make a nice addition to the standard library.
>From a
I posted last week about a need-for-speed patch that broke PEP 302
compliance, and asked if it should be fixed or reverted. I got exactly one
response which said "yes, it should be fixed or reverted", which
unfortunately didn't answer my question as to which one we should do. :)
If we don't r
Clearly they should be fixed. Whether in 2.5 or 2.6 I'll leave up to
Neal and Anthony.
On 7/26/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> http://www.python.org/sf/1525469 reports that SimpleXMLRPCServer.py
> still uses sys.exc_type and sys.exc_value when handling exceptions.
> These variables
http://www.python.org/sf/1525469 reports that SimpleXMLRPCServer.py
still uses sys.exc_type and sys.exc_value when handling exceptions.
These variables aren't thread-safe and sys.exc_info() is the better
way. I have a patch attached to the bug that fixes the problem.
Question 1: is this worth fix
I wrote a data persistence module called miniconf, aimed at making
easy to create and safely retrieve configuration info from external,
human-readable sources using Python syntax. I feel it would eventually
make a nice addition to the standard library.
The code was only newly refactored in this
2006/7/26, Raymond Hettinger <[EMAIL PROTECTED]>:
> Greg Ewing
> > And all of this is getting rather far away from where we
> > started, which was simply instrumenting a piece of code
> > to count floating point exceptions.
>
> I'm thinking of adding a note to the Py2.5 docs that the counting feat
Greg Ewing
> And all of this is getting rather far away from where we
> started, which was simply instrumenting a piece of code
> to count floating point exceptions.
I'm thinking of adding a note to the Py2.5 docs that the counting feature is
not
part of the standard and should not be expected t
"Neal Norwitz" <[EMAIL PROTECTED]> writes:
> On 7/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> >
>> > Yes, I definitely think dropping the X would make the warning go away.
>> > Do we want to check for a NULL pointer and raise an exception? The
>> > docs don't address the issue, so I th
Martin v. Löwis wrote:
> Neal Norwitz wrote:
>> # 61 Modules/_sqlite/cursor.c:599 Null pointer may be dereferenced
>>
>> Null pointer 'self->statement' that comes from line 674 may be
>> dereferenced by passing argument 1 to function
>> 'statement_mark_dirty' at line 599.
>
> Looks li
Nick Maclaren wrote:
> The compiled code has made a data structure temporarily inconsistent
> because the operation is safe (say, list insertion), and then gets an
> asynchronous interrupt (e.g. SIGINT). The SIGINT handler does some
> operation (e.g. I/O) that implicitly uses floating-point, whic
Neal Norwitz wrote:
> On 7/25/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Neal Norwitz wrote:
>> > # 74 Object/funcobject.c:143Suspicious deref of ptr before NULL check
>>
>> Not quite sure what it is complaining about, but
>>
>> else if (PyTuple_Check(closure)) {
>>
28 matches
Mail list logo
