Ian Bicking wrote:
> One advantage to this is that at each step something useful would be
> created. Better IPC would be useful for more than restricted execution.
> Or ways to create subinterpreters and communicate with them. Or making
> the interpreter startup faster, to facilitate spawning
> Kendall Clark wrote:
> > I don't know if the Ruby syntax for symbols, :foo, will work in
> > Python (though I think visually it's a good thing), but it would be
> > really nice to have symbols with *some* syntax in Python 3000.
> >
> > Again, this design request is based on aesthetics and fun: ha
Nick Coghlan wrote:
> This is why I think the first step in a solid Python restricted execution
> framework isn't an implementation activity but a research/scoping activity,
> looking at the various systems already out there, and the various trade-offs
> involved in each.
This might be a good p
Ivan Krstic wrote:
> Nick Coghlan wrote:
>> This is why I think the first step in a solid Python restricted
>> execution framework isn't an implementation activity but a
>> research/scoping activity, looking at the various systems already out
>> there, and the various trade-offs involved in each
Guido van Rossum wrote:
> I'd also like to point out (again?) that the "const-ness" of ALLCAPS
> is a red herring; in practice, we treat almost all imported names as
> constants, and in fact class and function names are generally
> considered constant. (I've also seen plenty of code that used ALLCA
> Michael Chermside wrote:
> > Ian Bicking writes:
> >> I propose that the self argument be removed from method definitions.
> >
> > This is not a new proposal. The fundamental problem is a perceived
> > mismatch between the argument list used for calling and the argument
> > list used in defining
On 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Ian Bicking wrote:
> > I propose that strings (unicode/text) shouldn't be iterable. Seeing this:
> >
> >
> >i
> >t
> >e
> >m
> >
> >1
> >
> >
> > a few too many times... it's annoying. Instead, I propose that strings
>
On 4/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > a few too many times... it's annoying. Instead, I propose that strings> > get a list-like view on their characters. Oh synergy!>> Another +1 here.And a moderate +0.1 here (we need to research the consequences more).
We can fairly easily
On 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Another potential generic function use case that occurred to me is the open()
> builtin.
>
> If that was extensible, the discussion about providing a nice filesystem path
> abstraction in the standard lib wouldn't need to waste any time on the
>
On 4/14/06, Thomas Wouters <[EMAIL PROTECTED]> wrote:
> We can fairly easily make strings non-iterable in the p3yk branch (and
> remove the default-iter in general), see how many tests it breaks ;P
I would do this in two steps: first remove the default-iter, see how
many tests it breaks.
But fir
> Guido van Rossum wrote:
> > What if, instead of adding registries mapping types to functions left
> > and right (in pickle, copy, pprint, who knows where else), we had a
> > convention of adding __foo_bar__ methods directly to the class dict?
> > This would require giving up the effective immutab
Ian Bicking wrote:
> Notably, Zope 3 does not include reloading (though it was
> included in Zope 2, in a more general form than just what reload()
> does). It was removed because of these corner cases where it doesn't
> work, and because when these corner cases happen the results are
> inscru
On 13/04/06 Ian Bicking said:
> I propose that the self argument be removed from method definitions. It
> would not be removed from other places, e.g., you'd still use
> "self.foo()", but the definition for that method would be "def foo():".
What happened to...
"Explicit is better than implic
Nick Coghlan wrote:
> Another potential generic function use case that occurred to me is the open()
> builtin.
I think this is a great idea. For example, I'd like to use open() to do
simple HTTP fetching (for simple GET requests).
This would allow for things somewhat similar to PHP's streams AP
Benji York wrote:
> Ian Bicking wrote:
>
>> Notably, Zope 3 does not include reloading (though it was included in
>> Zope 2, in a more general form than just what reload() does). It was
>> removed because of these corner cases where it doesn't work, and
>> because when these corner cases happe
On Apr 14, 2006, at 1:29 AM, Adam DePrince wrote:
> Perl on the other. Python is sort of in the middle. The question
> being
> asked here is "Does using plain strings for symbols make us too much
> like Perl, or will fixing it by introducing a symbol type make us too
> much like Java.
That's
On Apr 14, 2006, at 4:43 AM, Guido van Rossum wrote:
>> Kendall Clark wrote:
>>> I don't know if the Ruby syntax for symbols, :foo, will work in
>>> Python (though I think visually it's a good thing), but it would be
>>> really nice to have symbols with *some* syntax in Python 3000.
>>>
>>> Again
Guido van Rossum wrote:
> Then, on 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [...]
> class C:
> x = property("_get_x", "_set_x", "_del_x",
>"This is the x property")
> [...]
>
> (BTW I thought I implemented this but can't find any evidence.)
Name conventions are a bit b
On 4/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
But first we need to make all tests pass! If anyone wants to help outin the p3yk (sic) branch, please pick one of the failing tests, figureout why it fails, and propose a fix. (You can the fix in SF, assign it
to me, and mail me about it. I'll
Title: RE: [Python-3000] AST access (WAS: Adaptation vs. Generic Functions)
Talin wrote:
> What remains is a consise way to specify bound vs.
> unbound variables I would prefer not to have to
> restrict people to using a limited set of pre-declared
> undefined variables, i.e. X, Y, Z, etc.; p
Personally I like the idea (stolen from Perl, and others) of allowing
underscores in numbers as to group digits, for instance:
one_million = 1_000_000
maximum = 0xFF_FF_FF_FF
Once four or more identical digits appear in a row, I find a number
starts to become unwieldy, and separators would be a
21 matches
Mail list logo
