Phillip J. Eby wrote:
And what about code that needs to pass on a subset of a capability?
With one object == one capability, there is no such
thing as a subset of a capability -- the capabilities
are the atomic units at which you control access. So
you need to make them fine-grained enough
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)) {
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, which
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 like a problem.
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 think if we added a
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 to
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 feature is
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
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
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
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
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
make a
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 read
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 eliminate
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
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 that, my
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\PCbuildpython -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 or
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
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.
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 ; ).
[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 for
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 running
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
23 matches
Mail list logo
