At 02:21 PM 4/8/2006 +1000, Nick Coghlan wrote:
>>>Further, if all builtin function
>>>objects (including C function descriptors and method wrappers) were
>>>potentially generic,
>>This seems a rather extreme anticipation. I don't think anybody has
>>assumed this is where we might be going.
>
>Ther
At 10:57 AM 4/7/2006 -0700, Guido van Rossum wrote:
>Here I'm not so sure. Are you sure those results are unexpected? It
>seems you are saying that if I have a class C deriving from A and B
>(in that order) where both A and B implement a method foo(), and C
>doesn't, the call C().foo() would be amb
Vineet Jain wrote:
> Is it wishful thinking
> to have a python restricted exec mode which allows for:
I would say so, yes: this needs some dedicated maintainer who
comes up with an architecture, provides an initial implementation,
and then monitors ongoing changes to make sure nobody can bypass
t
Martin v. Löwis wrote:
> Vineet Jain wrote:
>> Is it wishful thinking
>> to have a python restricted exec mode which allows for:
>
> I would say so, yes: this needs some dedicated maintainer who
> comes up with an architecture, provides an initial implementation,
> and then monitors ongoing chang
Guido van Rossum sagte:
> On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> An Interface is an abstract class that you subclass to make it a concrete
>> implementation.
>
> That's not the view of most people who use the word interface these days. Not
> in Zope (see Fred Drake's post), not i
Nick Coghlan wrote:
> are somewhat staggering, and designing an in-process sandbox to cope
> with that is a big ask (and demonstrating that the sandbox actually
> *achieves* that goal is even tougher).
I was thinking along the lines of:
1. Start a "light" python interpreter, which by default wil
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> By the way, my rewrite of dominates() actually had a bug in it also, as did
> your original. Yours used an 'is' to compare the tuple signatures where it
> should've used ==, and mine checked individual types with 'is' instead of
> comparing th
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> >Even with the cache I put in? The hairy algorithm doesn't get invoked
> >more than once per actual signature (type tuple).
>
> You've measured it now, but yes, my own measurements of similar techniques
> in RuleDispatch showed the same effect,
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Naturally, if your goals are more modest, dealing only with actual
> arguments, no expressions, no operators other than 'isinstance()', no
> ability to apply boolean logic to the conditions (e.g. "isinstance(arg1,A)
> and isinstance(arg1,B)", o
Vineet Jain wrote:
> Nick Coghlan wrote:
>> are somewhat staggering, and designing an in-process sandbox to cope
>> with that is a big ask (and demonstrating that the sandbox actually
>> *achieves* that goal is even tougher).
> I was thinking along the lines of:
>
> 1. Start a "light" python int
From: Nick Coghlan <[EMAIL PROTECTED]>:
> But it would only be feasible if some angel came along and offered me (or
> somebody else) a full-time job doing it, because there's no way I could do it
> in my spare time and make it work in a usable fashion. Something like this
> would also need the s
On 8-apr-2006, at 5:44, Guido van Rossum wrote:
> On 4/7/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
>> Basic idea:
>>
>> [for ... in ...]+ if ...:
>> body
>>
>> A) it should be syntatically simple to parse.
>> B) it establishes a nice symetry with list comprehensions.
>
> Are you in caho
On 4/8/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
> On 8-apr-2006, at 5:44, Guido van Rossum wrote:
>
> > On 4/7/06, Crutcher Dunnavant <[EMAIL PROTECTED]> wrote:
> >> Basic idea:
> >>
> >> [for ... in ...]+ if ...:
> >> body
> >>
> >> A) it should be syntatically simple to parse.
> >> B) i
At 07:58 AM 4/8/2006 -0700, Guido van Rossum wrote:
>On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > By the way, my rewrite of dominates() actually had a bug in it also, as did
> > your original. Yours used an 'is' to compare the tuple signatures where it
> > should've used ==, and mine c
At 08:01 AM 4/8/2006 -0700, Guido van Rossum wrote:
>Check out the accelerated version in time_overloading.py in the svn
>sandbox/overloading/. It's mostly faster than the manual version!
>
>Anyway, you seem to be confirming that it's the speed with which we
>can do a cache lookup. I'm not worried
On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mostly just the API docs:
> http://peak.telecommunity.com/protocol_ref/module-protocols.html
I just finally found this too. PJE's website is really a confusing
maze; the only *source* for PyProtocols I've found so far is a CVS
repository that se
At 08:29 AM 4/8/2006 -0700, Guido van Rossum wrote:
>Of course, there are applications for more general predicates (like a
>dungeons&dragons game dispatcher) but to me they all seem a bit
>specialized to me.
Sure - but it would certainly be nice if RuleDispatch could tie into the
Python-supplied
At 01:39 PM 4/8/2006 -0700, Guido van Rossum wrote:
>For example, what if one library overloads bool(str) so
>that bool("False") == False, while another library assumes the
>traditional meaning (non-zero string => True)?
Presumably, the author of that code would be taken out and shot. :)
I suspe
At 01:39 PM 4/8/2006 -0700, Guido van Rossum wrote:
>On 4/7/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> > Mostly just the API docs:
> > http://peak.telecommunity.com/protocol_ref/module-protocols.html
>
>I just finally found this too. PJE's website is really a confusing
>maze; the only *source* f
On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> Those are mostly libraries, not frameworks, and for the most part you're
> not *integrating* them. You're not trying to make Perforce store
> information in your database, or to put a database API over Perforce, for
> example.
OK -- then I fe
At 03:26 PM 4/8/2006 -0700, Guido van Rossum wrote:
>On 4/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > Those are mostly libraries, not frameworks, and for the most part you're
> > not *integrating* them. You're not trying to make Perforce store
> > information in your database, or to put a
Antoine Pitrou wrote:
> 1. "Overloading" and "overriding" look very much the same for most
> people. In French the same word "surcharge" is used for both.
In statically typed languages, the distinction is that
overloading is resolved at compile time, whereas
overriding is resolved (at least partly
On 4/7/06, Vineet Jain <[EMAIL PROTECTED]> wrote:
> to have a python restricted exec mode which allows for:
>
> 1. Limit the memory consumed by the script
> 2. Limit access to file system and other system resources
> 3. Limit cpu time that the script will take
> 4. Be able to specify which modules
Crutcher Dunnavant wrote:
> Basic idea:
>
> [for ... in ...]+ if ...:
> body
-1, not enough advantage over writing out the
nested loops.
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
U
On Sat, Apr 08, 2006, Phillip J. Eby wrote:
>
> I suspect that the perspective of people like Alex, Jim, and myself is
> distorted by our being in consulting organizations (like Strakt, my
> group at Verio, and Zope corp.) where the focus is on having a toolkit
> that can be used to produce *multip
Is there a benefit to keeping vars()?
"vars([object]) -> dictionary\n\
\n\
Without arguments, equivalent to locals().\n\
With an argument, equivalent to object.__dict__.");
n
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mai
Nick Coghlan wrote:
> If yes, then you can get to object(), and hence to pretty much whatever C
> builtins you want.
Perhaps instead of attributes like __class__ and __subtypes__
there should be functions like classof() and subtypes() that
could be excluded from a restricted environment.
> But
On 4/8/06, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> Is there a benefit to keeping vars()?
>
> "vars([object]) -> dictionary\n\
> \n\
> Without arguments, equivalent to locals().\n\
> With an argument, equivalent to object.__dict__.");
I dunno; but let's not rush it.
--
--Guido van Rossum (home p
Guido van Rossum python.org> writes:
> Before we worry about the implementation overhead, we need to make
> sure that the resulting paradigm shift isn't going to destroy Python
> as we know it. We already have well-established and well-understood
> machinery for method lookup in a class hierarchy
I was browsing through the C# documentation for the String.format
function, because I'd noticed that a number of the suggestions
made in the string formatting thread were syntactically similar
to what is used in .Net.
A quick review of .Net string formatting:
Substitution fields are specified usi
30 matches
Mail list logo
