..
A goal is to use this in App Engine, yes? Which uses cgitb to report
errors? Which needs these restricted frame attributes to report the
values of variables when the error occurred?
Andrew Dalke
da...@dalkescientific.com
__
tav
> But the challenge was about doing `from safelite import FileReader`.
Though it doesn't say so on the first post on this thread nor your page at
http://tav.espians.com/a-challenge-to-break-python-security.html
It says "Now find a way to write to the filesystem from your
interpreter". Whic
ng)
try:
safelite.FileReader("whatever", "r", get_access)
except TypeError:
return get_access.f
f = open("busted.txt", "w")
f.write("Broke out of jail!\n")
f.close()
print "Message is:", repr(open("busted.txt").read())
.FileReader("whatever", "r", get_access)
except TypeError:
return get_access.f
f = open("busted.txt", "w")
f.write("Broke out of jail!\n")
f.close()
print "Message is:", repr(open("busted.txt").read())
Okay, my conclusion is
def f((a)=5)
is wrong, and the code should be changed to report a better error
message. I'll file a bug against that.
and I'm going with Brett suggestion that
[x for x in 1,]
is not supported because it's almost certainly a programming error. I
think therefore the
On Feb 19, 2008 1:38 PM, Andrew Dalke <[EMAIL PROTECTED]> wrote:
> def spam((a) = c):
> print a
On Feb 20, 2008 12:29 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> The error might be odd, but I don't see why that should be allowed
> syntax. Having a parameter sur
I'm finishing up a PLY lexer and parser for the current CVS version of
the Python grammar. As part of it I've been testing a lot of dark
corners in the grammar definition and implementation. Python 2.5 has
some small and rare problems which I'm pleased to note have been
pretty much fixed in Pytho
On 3/6/07, Mike Klaas <[EMAIL PROTECTED]> wrote:
> There's nothing quite like running help(func) and getting *args,
> **kwargs as the documented parameter list.
I think
>>> import resource
>>> help(resource.getpagesize)
Help on built-in function getpagesize in module resource:
getpagesize(...)
On 3/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I don't know too many good use cases for
> locals() apart from "learning about the implementation" I think this
> might be okay.
Since I'm watching this list for any discussion on the traceback
threads, I figured I would point out the most c
On 3/2/07, Adam Olsen <[EMAIL PROTECTED]> wrote:
> We can get more than half of the benefit simply by using a default
> __init__ rather than a python one. If you need custom attributes but
> they're predefined you could subclass the exception and have them as
> class attributes. Given that, is th
On 3/2/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> So, despite the existence of libraries that pre-create exceptions, how
> bad would it really be if we declared that use unsafe? It wouldn't be
> hard to add some kind of boobytrap that goes off when pre-created
> exceptions are raised multipl
On 3/2/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> This has given me another idea:
...
> Now, I'm not proposing that the raise statement should
> actually have the above syntax -- that really would be
> a step backwards. Instead it would be required to have
> one of the following forms:
>
>
On 3/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Since by far the most common use case is to create the
> exception in the raise statement, the behavior there won't be any
> different than it is today; the traceback on precreated objects will
> be useless, but folks who precreate them for p
On 2/28/07, James Y Knight <[EMAIL PROTECTED]> wrote:
> It seems to me that a stack trace should always be attached to an
> exception object at creation time of the exception, and never at any
> other time. Then, if someone pre-creates an exception object, they
> get consistent and easily explainab
Glyph:
> This seems like kind of a strange micro-optimization to have an impact
> on a language change discussion.
Just as a reminder, my concern is that people reuse exceptions (rarely)
and that the behavior of the "with_exceptions()" method is ambiguous
when that happens. It has nothing to do w
PJE:
> Then don't do that, as it's bad style for Python 3.x. ;-)
It's bad style for 3.x only if Python goes with this interface. If
it stays with the 2.x style then there's no problem. There
may also be solutions which are cleaner and which don't
mutate the exception instance.
I am not proposi
Guido's talk at PyCon said:
> Use raise E(arg).with_traceback(tb)
> instead of raise E, arg, tb
That seems strange to me because of the mutability. Looking through
the back discussions on this list I see Guido commented:
http://mail.python.org/pipermail/python-3000/2007-February/005689.ht
> On Thu, 15 Feb 2007 10:46:05 -0500, "A.M. Kuchling" <[EMAIL PROTECTED]> wrote:
> >It's hard to debug the resulting problem. Which level of the *12*
> >levels in the stack trace is responsible for a bug? Which of the *6*
> >generic calls is calling the wrong thing because a handler was set up
>
On 2/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote
in response to [EMAIL PROTECTED]:
> As far as I can tell, you still haven't even clearly expressed what your
> needs are, let alone whether or not Twisted is suitable. In the reply
> you're citing, you said that "this" sounded like something
I was the one on the Stackless list who last September or so
proposed the idea of monkeypatching and I'm including that
idea in my presentation for PyCon. See my early rough draft
at http://www.stackless.com/pipermail/stackless/2007-February/002212.html
which contains many details about using Stac
Andrew:
> >>> urlparse.urljoin("http://blah.com/";, "..")
> 'http://blah.com/'
> >>> urlparse.urljoin("http://blah.com/";, "../")
> 'http://blah.com/../'
> >>> urlparse.urljoin("http://blah.com/";, "../..")
> 'http://blah.com/'
/F:
> as I said, today's urljoin doesn't guarantee that the output is
Martin:
> It still should be possible to come up with examples for these as
> well, no? For example, if you pass a relative URI as the base
> URI, what would you like to see happen?
Until two days ago I didn't even realize that was an incorrect
use of urljoin. I can't be the only one. Hence, rai
Me [Andrew]:
> > As this is not a bug, I have added the feature request 1591035 to SF
> > titled "update urlparse to RFC 3986". Nothing else appeared to exist
> > on that specific topic.
Martin:
> Thanks. It always helps to be more specific; being less specific often
> hurts.
So does being more
Martin:
> Unfortunately, you didn't say which of these you want explained.
> As it is tedious to write down even a single one, I restrain to the
> one with the What?! remark.
>
> urlparse.urljoin("http://blah.com/a/b/c";, "../../../..") # What?!
> > 'http://blah.com/'
The "What?!" is in cont
Steve:
> > I'm darned if I know. I simply know that it isn't right for http resources.
/F:
> the URI specification disagrees; an URI that starts with "../" is per-
> fectly legal, and the specification explicitly states how it should be
> interpreted.
I have looked at the spec, and can't figure o
Martin:
> Just in case this isn't clear from Steve's and Fredrik's
> post: The behaviour of this function is (or should be)
> specified, by an IETF RFC. If somebody finds that non-intuitive,
> that's likely because their mental model of relative URIs
> deviate's from the RFC's model.
While I didn'
glyph:
> Path manipulation:
>
> * This is confusing as heck:
>>>> os.path.join("hello", "/world")
>'/world'
>>>> os.path.join("hello", "slash/world")
>'hello/slash/world'
>>>> os.path.join("hello", "slash//world")
>'hello/slash//world'
>Trying to formulate a general rul
Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> Real-world usage case for import __main__? Otherwise, I say screw it :)
I have used it as a workaround for timeit.py's requirement that I pass
it strings instead of functions.
>>> def compute():
... 1+1
...
>>> import timeit
>>> t = timeit.Timer("__m
On 6/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> - I would average the timings of runs instead of taking the minimum value as
> sometimes bench marks could be running code that is not deterministic in its
> calculations (could be using random numbers that effect convergence).
I would rewr
Tim:
> A lot of things get mixed up here ;-) The _mean_ is actually useful
> if you're using a poor-resolution timer with a fast test.
In which case discrete probability distributions are better than my assumption
of a continuous distribution.
I looked at the distribution of times for 1,000 repe
On 6/2/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> It's interesting that even pressing a key on your keyboard
> will cause forced context switches.
When niceness was first added to multiprocessing OSes people found their
CPU intensive jobs would go faster by pressing enter a lot.
On 6/2/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> Hardly a setting in which to run comparison tests, seems to me.
The point though was to show that the time distribution is non-Gaussian,
so intuition based on that doesn't help.
> > Using the minimum looks like the way to go for calibration.
>
>
M.-A. Lemburg:
The approach pybench is using is as follows:
...
The calibration step is run multiple times and is used
to calculate an average test overhead time.
One of the changes that occured during the sprint was to change this algorithm
to use the best time rather than the average. Us
Me [Andrew Dalke] said:
> The relevant code in stringobject uses PySequence_Fast_GET_ITEM(seq,
> i),
> which likely doesn't know about my derived __getitem__.
Oops, I didn't know what the code was doing well enough. The
relevant problem is
seq = PySequence_Fast(ori
The Sourceforge tracker is kaputt so I'm sending it here, in part
because the effbot says it's interesting.
I can derive from list and override __getitem__
>>> class Spam(list):
... def __getitem__(self, i):
... print i
... return 2
...
>>> Spam()[1]
1
2
>>> Spam()[9]
9
2
>>>
Now c
35 matches
Mail list logo
