On 4/3/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > the source code is available via the above link; I'll post the ZIP file
> > some-
> > where tomorrow (drop me a line if you want the URL).
>
> I found some free space on the effbot.org server, so anyone inter-
> ested can get the current ZIP
On 4/4/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>
>
> On 4/4/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
> >
> > Of course anyone who is interested can run the Twisted test suite very
> easily and take a look at the failures themselves (if you have Twisted
> installed, "trial twisted" w
On 4/5/06, Donovan Baarda <[EMAIL PROTECTED]> wrote:
> G'day,
>
> Just noticed on Debian (testing), Ubuntu (warty?), and RedHat (old)
> based systems Python's time.strptime() seems to ignore the environment's
> Locale and just uses "C".
>
> Last time I looked at this, time.strptime() leveraged off
On 4/6/06, Peter Åstrand <[EMAIL PROTECTED]> wrote:
>
> Hi everyone. I've been away from Python dev for a while, but I've noticed
> that I'm assigned to quite many subprocess bugs (14 or so) that needs some
> care.
>
> The first question is: Am I the right person to take care of these? I do
> have
OK, I am going to write the PEP I proposed a week or so ago, listing
all modules and packages within the stdlib that are maintained
externally so we have a central place to go for contact info or where
to report bugs on issues. This should only apply to modules that want
bugs reported outside of t
On 4/9/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > - expat
>
> Not sure whether you mean the Expat parser proper here, or the pyexpat
> module: both are externally maintained,
I was thinking the parser, but if pyexpat is extern
On 4/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Can someone (Martin, Barry?) post this on python.org (I don't think
> > this necessarily needs to be put into svn and I don't have any access
> > but svn) so Fredrik
On 4/10/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Brett Cannon wrote:
> > OK, I am going to write the PEP I proposed a week or so ago, listing
> > all modules and packages within the stdlib that are maintained
> > externally so we have a central place t
On 4/8/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> OK, I am going to write the PEP I proposed a week or so ago, listing
> all modules and packages within the stdlib that are maintained
> externally so we have a central place to go for contact info or where
> to report bug
On 4/16/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > Basically, from all the replies I have gotten has said that package
> > that were/are externally maintained either considers Python HEAD as
> > the current version or watches
Bug 532646 is a check for recursive __call__ methods where it is just
set to an instance of the same class::
class A:
pass
A.__call__ = A()
a = A()
try:
a() # This should not segfault
except RuntimeError:
pass
else:
raise TestFailed, "how could this not have overflowed the stack?"
On 4/18/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Brett,
>
> On Mon, Apr 17, 2006 at 05:34:16PM -0700, Brett Cannon wrote:
> > + if (meth == self) {
> > + PyErr_SetString(PyExc_RuntimeError,
> > +
Definitely an intriguing idea! I am +0 just because I don't know how
needed it is, but it is definitely cool.
As for your open issues, ditching __metaclass__ is fine if this goes
in, but I would keep 'class' around as simplified syntactic sugar for
the common case.
-Brett
On 4/18/06, Steven Bet
On 4/24/06, Michael Foord <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I'm working on a parser for part of the Python language (expressions but
> not statements basically). I'm using PLY to generate the parser and it's
> mostly done.
>
> I've hit on what looks like a fundamental ambiguity in the Pyt
I am starting to hash out what the Call for Trackers is going to say
on the Infrastructure mailing list. Laura Creighton suggested we have
a list of features that we would like to see and what we all hate
about SF so as to provide some guidelines in terms of how to set up
the test trackers that pe
lease look over your package information and let
me know if you want anything changed?
---
PEP: XXX
Title: Externally Maintained Packages
Version: $Revision: 43251 $
Last-Modified: $Date: 2006-03-23 06:28:55 -0800 (Thu, 23 Mar 2006) $
Author:
On 4/2/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Tim Peters wrote:
> > For gcc we _could_ solve it in the obvious way, which I guess Martin
> > was hoping to avoid: change Unixish config to detect whether the
> > platform C supports the "z" format modifier (I believe gcc does), and
> > if
On 4/25/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > here is the rough draft of the PEP for packages maintained externally
> > from Python itself. There is some missing, though, that I would like
> > help filling in.
> >
> > I don
On 4/26/06, Gerhard Häring <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > here is the rough draft of the PEP for packages maintained externally
> > from Python itself. There is some missing, though, that I would like
> > help filling in.
> >
> >
On 4/26/06, Gerhard Häring <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > OK, I am going to write the PEP I proposed a week or so ago, listing
> > all modules and packages within the stdlib that are maintained
> > externally so we have a central place to go for c
On 4/26/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Brett Cannon]
> >> I created patch 1474907 with a fix for it. Checks if %zd works for
> >> size_t and if so sets PY_FORMAT_SIZE_T to "z", otherwise just doesn't
> >> set the macro def.
> &g
d I came upon
> Brett Cannon's thesis in which he tweaks the compiler and shows that
> type-defing python would not help the compiler achieve a 5% performace
> increase.
>
> Brett Cannon, "Localized Type Inference of Atomic Types in Python":
> http://www.ocf.berk
gives me an OK assuming no
one else finds a problem with it.
-
PEP: XXX
Title: Externally Maintained Packages
Version: $Revision: 43251 $
Last-Modified: $Date: 2006-03-23 06:28:55 -0800 (Thu, 23 Mar 2006) $
Author: Brett Cannon <[EMAIL PROTEC
On 4/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/30/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> > Nick Coghlan wrote:
> > > Collin Winters has done the work necessary to rename PEP 309's functional
> > > module to functools and posted the details to SF [1].
> > >
> > > I'd like to t
On 4/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 4/30/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > A few things from the pre-alpha2 context management terminology review have
> > had a chance to run around in the back of my head for a while now, and I'd
> > like to return to a topic
Signature objects (which has been lightly discussed on python-3000,
but I realize should be retargeted to 2.6 since there is no
incompatibility problems) are the idea of having an object that
represents the parameters of a function for easy introspection. But
there are two things that I can't quit
On 5/1/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Mon, May 01, 2006, Brett Cannon wrote:
> >
> > But there are two things that I can't quite decide upon.
> >
> > One is whether a signature object should be automatically created
> > for every function.
On 5/2/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
> > One is whether a signature object should be automatically created for
> > every function. As of right now the PEP I am drafting has it on a
> > per-need basis and have it assigned to __signatu
On 5/15/06, Tim Peters <[EMAIL PROTECTED]> wrote:
[Tim]> "Something went wrong" here on Windows. The Windows buildbot slaves> other than mine eventually died with:>> """> ...> test_tarfile>> command timed out: 1200 seconds without output
> """:>> I was working on my box at the time, and it became
On 5/15/06, Richard Jones <[EMAIL PROTECTED]> wrote:
I just built 2.5 SVN on my OS X 10.4 laptop. I ran into the missingsys/statvfs.h problem that has been reported here in the past. Tosolve the problem I needed to upgrade my XCode install from 1.1 to2.2.1 - the missing header files (there was actu
Can someone install the attached SSH key (it's for my work machine)? The fingerprint is:: cd:69:15:52:b2:e5:dc:2e:73:f1:62:1a:12:49:2b:a1 [EMAIL PROTECTED]Also, how hard is it to have a specific key uninstalled? The reason I ask is that my internship is only for three months so that after that th
Since no Python code should be generating the warning (I would double-check that, obviously), I say take it out. At least from a PEP 352 perspective there is nothing about keeping it (or removing it).-Brett
On 5/26/06, Richard Jones <[EMAIL PROTECTED]> wrote:
On 25/05/2006, at 9:00 PM, Jim Jewett
On 5/30/06, Steven Bethard <
[EMAIL PROTECTED]> wrote:
On 5/30/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> So, first step in my mind is settling if we want to add one more depth to
> the stdlib, and if so, how we want to group (not specific groupings, just
> general gui
On 5/30/06, Steven Bethard <[EMAIL PROTECTED]> wrote:
[Steven Bethard]> I think that having a package level that exactly matches the divisions> in the Library Reference (http://docs.python.org/lib/lib.html) would
> be great.[Brett Cannon]> Makes sense to me.>[snip]> > 5.
On 5/30/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
On Tue, May 30, 2006 at 03:36:02PM -0600, Steven Bethard wrote:> That sounds about reasonable. One possible grouping:Note that 2.5's library reference has a different chapter organizationfrom 2.4's. See <
http://docs.python.org/dev/lib/lib.html
On 6/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 6/1/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:> I didn't know it was assigned to me. I guess SF doesn't send any> notifications, and neither did Georg, so your email is the very first time
> that I've heard of it.This is a longstanding S
On 6/3/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
Georg Brandl wrote:> I've worked on two patches for NeedForSpeed, and would like someone> familiar with the areas they touch to review them before I check them> in, breaking all the buildbots which aren't broken yet ;)
>> They are:>> http://python.
frastructure at python.org .- Brett Cannon Chairman, Python Software Foundation Infrastructure committee
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pyt
If you run ``import array; int(buffer(array.array('c')))`` the
interpreter will segfault. While investigating this I discovered that
buffer objects, for their tp_as_buffer->bf_getcharbuffer, return the
result by calling the wrapped object bf_getreadbuffer or
bf_getwritebuffer. This is wrong since
On 6/6/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 6/6/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > If you run ``import array; int(buffer(array.array('c')))`` the
> > interpreter will segfault. While investigating this I discovered that
>
clarifying the docs.
-Brett
> Kristján
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Cannon
> Sent: 6. júní 2006 22:30
> To: Python Dev
> Subject: [Python-Dev] How to fix the buffer object's broken char buffersupport
&g
I fixed the crasher for ``int(buffer(array.array('c')))`` by making
buffer objects operate properly. Problem is that by doing so I broke
the ctypes tests with a bunch of similar errors::
==
ERROR: test_endian_double (ctypes.test.
On 6/8/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> I fixed the crasher for ``int(buffer(array.array('c')))`` by making> buffer objects operate properly. Problem is that by doing so I broke> the ctypes tests with a bunch of similar errors::
You have n
On 6/8/06, Tim Peters <[EMAIL PROTECTED]
> wrote:
FYI, here's the minimal set of failing tests:$ python_d ../Lib/test/regrtest.py test_file test_optparsetest_filetest_optparsetest test_optparse failed -- Traceback (most recent call last): File "C:\Code\python\lib\test\test_optparse.py", line 1042,
On 6/8/06, Tim Peters <[EMAIL PROTECTED]> wrote:
[Tim]>> FYI, here's the minimal set of failing tests: $ python_d ../Lib/test/regrtest.py test_file test_optparse>> test_file>> test_optparse>> test test_optparse failed -- Traceback (most recent call last):
>> File "C:\Code\python\lib\test\test
On 6/8/06, Tim Peters <[EMAIL PROTECTED]> wrote:
...[Tim]>> What revision was your laptop at before the update? It could help a>> lot to know the earliest revision at which this fails.[Brett]> No clue. I had not updated my local version in quite some time since most
> of my dev as of late has be
On 6/8/06, Tim Peters <[EMAIL PROTECTED]> wrote:
Well, this sure sucks. This is the earliest revision at which the tests fail:"""r46752 | georg.brandl | 2006-06-08 10:50:53 -0400 (Thu, 08 Jun 2006) | 3 linesChanged paths: M /python/trunk/Lib/test/test_file.py
Convert test_file to unittest."""If
On 6/9/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
Neal Norwitz wrote:> It's June 9 in most parts of the world. The schedule calls for beta 1> on June 14. That means there's less than 4 days until the expected> code freeze. Please don't rush to get everything in at the last
> minute. The build
I discovered last night that if you run ``./python.exe -Wi`` the interpreter exists rather badly:: Fatal Python error: PyThreadState_Get: no current threadAnyone else seeing this error on any other platforms or have an inkling of what checkin would cause this?
-Brett
__
On 6/10/06, Johann C. Rocholl <[EMAIL PROTECTED]> wrote:
I'm working on simple module to write PNG image files in pure python.Adding it to the standard library would be useful for people who wantto create images on web server installations without gd and imlib, oron platforms where the netpbm tools
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Martin v. Löwis wrote:> Then I guess we should deal with before 2.5b1, and delay 2.5b1 until the> status of each of these has been clarified.>> Each maintainer should indicate whether he is happy with a "this is
> part of Python" approach. If so,
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> But I don't think this is trying to say they don't care. People just want> to lower the overhead of maintaining the distro.well, wouldn't the best way to do that be to leave all non-trivial maint
On 6/12/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Phillip J. Eby wrote:> I'd still rather have a Packages/ directory, but beggars can't be > choosers.there's plenty of time to work on that for 2.6...I have started a thread on python-3000 to try to get a PEP pulled together to solidify what we wa
On 6/12/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 6/12/06, Guido van Rossum <[EMAIL PROTECTED]
> wrote:
Perhaps issues like these should motivate us to consider a differentsource control tool. There's a new crop of tools out that could solvethis by having multiple repositories that can be sy
It's sounding like a rewording of PEP 360 would help this whole external code issue. If it was changed to say that non-API changes could be directly checked in would that help?That would mean the PEP would list the contact person and what external version corresponds to what Python release. Basic
On 6/12/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 02:00 AM 6/13/2006 +0200, Giovanni Bajo wrote:>IMO, the better way is exactly this you depicted: move the official>development>tree into this Externals/ dir *within* Python's repository. Off that, you can
>have your own branch for experimenta
On 6/14/06, Gerhard Häring <[EMAIL PROTECTED]> wrote:
Co-posting to python-dev in the hope of getting help of people verifyingmy suspicion ...Gerhard Häring wrote:> [...]> For some reason, they don't seem to have picked up the changed tests of> the sqlite3 module. At least the error messages look e
On 6/18/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:> Ka-Ping Yee wrote:> > Anyway, it looks like someone has added this module to the list of
> > backward-compatible modules in PEP 291. Regarding whether we want> > it to be on that list (i.e. whether or not this backward-compatibility> > shou
On 6/18/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
Georg Brandl wrote:> Georg Brandl wrote:>> In abstract.c, there are many error messages like type_error("object does not support item assignment"); It helps debugging if the object's type was prepended.
>> Should I go through the code and
[skipping answering the numeric-specific questions since I am no math expert =) ]On 6/15/06, Nick Maclaren <[EMAIL PROTECTED]
> wrote:As I have posted to comp.lang.python, I am not happy with Python's
numerical robustness - because it basically propagates the 'features'of IEEE 754 and (worse) C99.
On 6/15/06, Titus Brown <[EMAIL PROTECTED]> wrote:
Folks,I've just run a code coverage report for the python2.4 branch:http://vallista.idyll.org/~t/temp/python2.4-svn/This report uses my figleaf code,
http://darcs.idyll.org/~t/projects/figleaf-latest.tar.gzVery nice, Titus!
I'm int
On 6/18/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
A question has been asked about branching release25-maint at the timeof beta1. I was actually thinking about doing this for 2.5rc1 - oncewe're in release candidate stage we want to really be careful aboutcheckins. I'm not sure it's worth branchi
On 6/19/06, Benji York <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> But it does seem accurate; random checking of some modules that got high> but not perfect covereage all seem to be instances where dependency> injection would be required to get the tests to work since they
http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/676/step-compile/0Looks like Tim's XP box is crapping out on a header file included from Tcl/Tk. Did the Tcl/Tk folk just break something and we are doing an external svn pull and thus got bit by it?
-Brett
__
I have been working on a design doc for restricted execution of Python
as part of my dissertation for getting Python into Firefox to replace
JavaScript on the web. Since this is dealing with security and
messing that up can be costly, I am sending it to the list for any
possible feedback.
I have
On 6/22/06, Gerhard Häring <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> I have been working on a design doc for restricted execution of Python> [...]All the rest of the API made sense to me, but I couldn't understand whyPyXXX_MemoryFree
is needed. How could memory usage possibl
On 6/22/06, Gerhard Häring <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 6/22/06, *Gerhard Häring* <[EMAIL PROTECTED] [EMAIL PROTECTED]>> wrote:>> Brett Cannon wrote:
> > I have been working on a design doc for restricted execution of> Python>
On 6/24/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> Yep. That API will be used directly in the changes to pymalloc and> PyMem_*() macros (or at least the basic idea). It is not *only* for> extension modules but for the core as well.
>> Existing
On 6/24/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
On Jun 24, 2006, at 2:46 AM, Nick Coghlan wrote:> Brett Cannon wrote:>> Yep. That API will be used directly in the changes to pymalloc and>> PyMem_*() macros (or at least the basic idea). It is not *only* for
>> ex
Python-Dev is about Python the language and its development. Questions on its use (and build) should be posted elsewhere (I would try comp.lang.python).-BrettOn 6/26/06,
J. Jeffrey Close <[EMAIL PROTECTED]> wrote:
Hi all,I have been trying for some time to build Python 2.4.xfrom source on OS X 10
On 6/26/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
Hi, Brett.> I have been working on a design doc for restricted execution of PythonI'm excited to see that you're working on this.Yeah, I just hope I have a design that works. =)
> as part of my dissertation for getting Python into Firefox to repl
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
(1) Is it impossible for an interpreter to switch between trusted anduntrusted modes? This is probably a reasonable restriction, but worthcalling out loudly in the docs.Yes, you should not change the state once the interpreter is used for executio
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:> > (2) For the APIs returning an int, it wasn't clear what that int
> > would be, other than NULL => in
If you look at that crasher, you will notice that recursion depth is set to 1 << 30 before any code is run. If you remove that setting high setting and go with the default then the test doesn't crash and raises the appropriate RuntimeError.
Setting the recursion depth to such a high number will cr
On 6/27/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <
[EMAIL PROTECTED]> wrote:
If you look at that crasher, you will notice that recursion depth is set to 1 << 30 before any code is run. If you remove that setting high setting and go with the def
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> My worry with this is that by providing checking functions that just return> true or false that people will rely on those too much and have logic errors
> in their check a
On 6/27/06, Michael Hudson <[EMAIL PROTECTED]> wrote:
"Brett Cannon" <[EMAIL PROTECTED]> writes:> If you look at that crasher, you will notice that recursion depth is set> to 1 << 30 before any code is run. If you remove that setting high
> setting and go w
On 6/27/06, Scott David Daniels <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:>> ...>> Caps and current usage should also be available (though read-only)
>> from python; it is quite sensible to spill some cache
On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:>> > On 6/27/06, Brett Cannon <
[EMAIL PROTECTED]> wrote:> Shouldn't be as long as you put the cal
On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:>> > (5) I think file creation/writing should be capped rather than> > binary; it is reasonable to say "You can create a single temp file up
> > to 4K&q
On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:> On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> >> > > (5) I think file creation/writing should be capped rather than
> > > binary; it is re
On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote:> On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:> > On 6/27/06, Brett Cannon <
[EMAIL PROTECTED]> wrote:> > >> > > > (5) I th
On 6/27/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> The plan is to allow pure Python code to be embedded into web pages like> _javascript_. I am not going for the applet approach like Java.Java support is now just a plug-in. Should be easy to make a Python
plug-in system that works the same way
On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> > - File size should be rounded up to some block size (512 if you don't
> > have filesystem spec
On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> > - File size should be rounded up to some block size (512 if you don't
> > have filesystem
On 6/28/06, Trent Mick <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> The plan is to allow pure Python code to be embedded into web pages like> _javascript_. ...> ...Then again, Mark Hammond has already done a bunch of work for pyXPCOM, so getting Python compiled right into
On 6/28/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> Yep, it would be. Then again, Mark Hammond has already done a bunch of work> for pyXPCOM, so getting Python compiled right into Firefox itself shouldn't> be too bad.Of course, that's the road Sun first went down with Java, and that
turned out n
On 6/28/06, Trent Mick <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> > > The idea is that there be a separate Python interpreter per web> > > browser page instance.>> > I think there may be scaling issues there. _javascript_ isn't doing that
> >
On 6/28/06, Mark Hammond <[EMAIL PROTECTED]> wrote:
Bob writes:> I don't know how _javascript_ is doing it yet. The critical thing> for me for this month was trying to come up with a security model.I don't fully understand how JS does it either, certainly not in any detail.
I know that it uses the
I have gotten some questions from people about why cripple 'file' (and probably 'socket' if they cared), asking whey I didn't just remove the 'file' built-in from built-ins. Problem is that I still want to provide some protection for files.
So an option I have been thinking of is making sure 'file
On 6/29/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote:> My worry, as has been from the start, is containing 'file'. The ``del> __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff
>
On 6/30/06, Frank Wierzbicki <[EMAIL PROTECTED]> wrote:
Hello all,According to the thread that includeshttp://mail.python.org/pipermail/python-dev/2006-June/065727.htmlthere will be some effort in
2.6 to make the tests in Python moreconsistent. I would like to help with that effort, partly to sne
On 6/30/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
Hi Brett,On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote:> 1) Is removing 'file' from the builtins dict in PyInterpreterState (and> maybe some other things) going to be safe enough to sufficiently hide 'fi
Lib/test/crashers/xml_parsers.py is a crasher that involves expat (bug report at http://python.org/sf/1296433). What is at issue here is that there is a 'for' loop in expat where the status of the parser is not checked. Because of this, the loop continues on its merry way, which is a problem beca
On 6/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> The question is how long do we wait for the expat developers to patch> and do a micro release? Do we just leave this possible crasher in and> just rely entirely on the expat developers, or do we
On 6/30/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
On Fri, 30 Jun 2006, Brett Cannon wrote:> On 6/30/06, Armin Rigo <[EMAIL PROTECTED]> wrote:> > >>> object.__subclasses__()> > [..., ]
> >> > Maybe this one won't work if __subclasses_
On 6/30/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
Brett Cannon wrote:> 1) Is removing 'file' from the builtins dict in PyInterpreterState (and> maybe some other things) going to be safe enough to sufficiently hide> 'file' confidently (short of someone being stupi
On 7/4/06, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
Hi Brett,Here are some comments on the description of the restricted executionmodel that you posted.> When referring to the state of an interpreter, it is either "trusted" or> "untrusted". A trusted interpreter has no restrictions imposed upon any
I have created a branch in svn off of HEAD for holding the sandboxing
work. It's called bcannon-sandboxing and I have checked in the design
doc in the root as sandboxing_design_doc.txt . You can keep an eye on
the checkout message for incremental changes, but I will email the list
once I have gon
On 7/5/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
Ka-Ping Yee writes:> If you mean getting from a trusted interpreter to an untrusted> interpreter -- then how is a resource going to travel between> interpreters?Brett Cannon responds:> Beats me, but I am always scared of
3001 - 3100 of 3314 matches
Mail list logo