On 4/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 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 alread
Another grab-bag of language ideas / wishes. Some of these are
items that have been raised before on other lists - I want to get them
written down so that they can be rejected quickly :)
1) I don't know if this is already on the table, but I sure would like
to be able to have more options as far a
On Sat, Apr 15, 2006 at 10:32:21AM +, Talin wrote:
> 2a) One particularly useful variation of *list (again, one which I have
> brought up before, as have others), is the "yield *" syntax. The primary
> use case is for chained generators, that is a generator that is yielding
> the output of mult
On Fri, 14 Apr 2006, Ian D. Bollinger wrote:
> 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 numbe
John J Lee wrote:
> On Fri, 14 Apr 2006, Ian D. Bollinger wrote:
>
>
>> 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
Talin <[EMAIL PROTECTED]> wrote:
> 6) Although I would not want to propose that Python adopt C's
> 'assignment is an expression' behavior, I find myself constantly
> wanting to combine the following two statements into one:
>
>m = re.match( ... )
>if m:
> # do something with m
I'm
Giovanni> I'm sure you were talking more generically, but as for this
Giovanni> specific case (which is indeed very common), I always wondered
Giovanni> why re couldn't export wrappers around bound methods of the
Giovanni> last match object, so to allow:
Giovanni> if re.match(.
Ian Bicking wrote:
> Class.some_method(self, blah) seems like a corner case. How often do
> you do that?
Very frequently, when calling inherited __init__ methods.
> If it is calling a superclass method, then super(Class,
> self).some_method() should be used
That's a matter of opinion. In the
Michael Chermside wrote:
> def self.my_method(arg1, arg2):
> # body goes here
Unfortunately, this would clash with another
potential future feature, that of allowing defs
into arbitrary lvalues instead of just names.
I think I'd rather it was reserved for that.
--
Greg
__
Adam DePrince wrote:
> IIRC one of the goals
> with P3K is to allow Python to compile unicode source files ...
> Personally, I rather like the direction of the symbols idea, but am
> unsure if I like the :symbol form for the literal. I give it a +0.5.
Putting these thoughts together, we could u
Jim Jewett wrote:
> (I wouldn't want to give up slicing, though, which might make the
> no-iteration trickier.)
You'd want to allow slicing but not indexing -- i.e.
s[i:j] is okay but not s[i].
--
Greg
___
Python-3000 mailing list
[email protected]
On Sun, Apr 16, 2006, Greg Ewing wrote:
> Jim Jewett wrote:
>>
>> (I wouldn't want to give up slicing, though, which might make the
>> no-iteration trickier.)
>
> You'd want to allow slicing but not indexing -- i.e.
> s[i:j] is okay but not s[i].
Ewww. I've been getting steadily less comfortabl
pobox.com> writes:
> Giovanni> I'm sure you were talking more generically, but as for this
> Giovanni> specific case (which is indeed very common), I always wondered
> Giovanni> why re couldn't export wrappers around bound methods of the
> Giovanni> last match object, so to allow
Talin acm.org> writes:
> 2) A suggestion which I've seen others bring up before is the use of
> the * operator for tuple packing / unpacking operations, i.e.:
>
> a, *b = (1, 2, 3)
I wanted to add another case that I run across in my code a lot.
I often times want to split off a single lea
14 matches
Mail list logo
