> At 08:53 AM 12/8/2006 -0600, Guido van Rossum wrote:
>
>>I've been thinking about this too, and I think it's reasonable to let
>>the metaclass provide the dict to be used as locals.
>
> [snip]
>
>>class C(B1, B2, metaclass=Foo):
If there's to be a special syntax for this, I don't
think it sho
On Fri, Dec 08, 2006 at 11:58:38AM -0800, Brett Cannon wrote:
> On 12/8/06, Talin <[EMAIL PROTECTED]> wrote:
> >
> >One other minor brainstorm before I head off to work: I'd like function
> >decorators to work with assignment statements as well as 'def' statements.
> >
> >Use case:
> >
> >class
On 12/8/06, Talin <[EMAIL PROTECTED]> wrote:
> One other minor brainstorm before I head off to work: I'd like function
> decorators to work with assignment statements as well as 'def' statements.
>
> Use case:
>
> class Foo:
>
>@private
>def myfunc():
> pass
>
>
Bill Janssen wrote:
> Ron,
>
>> I'm wonder how many places in pythons syntax requires or produces specific
>> types. And if listing and organizing these commonly used "syntactically
>> necessary" types would be useful to determine the minimum list of ABC's.
>> (More
>> can always be added late
Talin wrote:
> One other minor brainstorm before I head off to work: I'd like function
> decorators to work with assignment statements as well as 'def' statements.
>
> Use case:
>
> class Foo:
>
>@private
>def myfunc():
> pass
>
>@private
>selected
At 01:20 PM 12/9/2006 +1300, Greg Ewing wrote:
>Talin wrote:
> > In other words, the
> > __metaclass__ statement would have a side-effect of replacing the
> > locals() dict with a mapping object supplied by the metaclass.
>
>__metaclass__ isn't a statement, it's just an
>attribute that is interp
Talin wrote:
> In other words, the
> __metaclass__ statement would have a side-effect of replacing the
> locals() dict with a mapping object supplied by the metaclass.
__metaclass__ isn't a statement, it's just an
attribute that is interpreted in a special way
*after* the class namespace has be
On 12/8/06, Talin <[EMAIL PROTECTED]> wrote:
One other minor brainstorm before I head off to work: I'd like function
decorators to work with assignment statements as well as 'def' statements.
Use case:
class Foo:
@private
def myfunc():
pass
@private
At 08:53 AM 12/8/2006 -0600, Guido van Rossum wrote:
> I've been thinking about this too, and I think it's reasonable to let
> the metaclass provide the dict to be used as locals.
[snip]
> class C(B1, B2, metaclass=Foo):
>...
On 12/8/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I definitely
Talin schrieb:
> Guido van Rossum wrote:
>> I've been thinking about this too, and I think it's reasonable to let
>> the metaclass provide the dict to be used as locals. This is easier
>> when the metaclass is given in the class header, e.g. by way of a base
>> class, or through the default metacla
Ron,
> I'm wonder how many places in pythons syntax requires or produces specific
> types. And if listing and organizing these commonly used "syntactically
> necessary" types would be useful to determine the minimum list of ABC's.
> (More
> can always be added later.)
I think a lot of the syn
On Fri, Dec 08, 2006 at 09:48:04AM -0800, Talin wrote:
> One other minor brainstorm before I head off to work: I'd like function=
=20
> decorators to work with assignment statements as well as 'def' statements.
>=20
> Use case:
>=20
> class Foo:
>=20
>@private
>def myfunc():
>
Guido van Rossum wrote:
> I've been thinking about this too, and I think it's reasonable to let
> the metaclass provide the dict to be used as locals. This is easier
> when the metaclass is given in the class header, e.g. by way of a base
> class, or through the default metaclass. Although the defa
At 08:53 AM 12/8/2006 -0600, Guido van Rossum wrote:
>I've been thinking about this too, and I think it's reasonable to let
>the metaclass provide the dict to be used as locals. This is easier
>when the metaclass is given in the class header, e.g. by way of a base
>class, or through the default met
On 12/8/06, Talin <[EMAIL PROTECTED]> wrote:
> Another mini-brainstorm, which is how to represent PJE's 'defop' syntax
> without adding any keywords:
>
> Alternative 1. Omitting the function name in 'def' statements.
[snip]
>@overload(len):
>def (self):
> ... compute len( self ) ...
[
One other minor brainstorm before I head off to work: I'd like function
decorators to work with assignment statements as well as 'def' statements.
Use case:
class Foo:
@private
def myfunc():
pass
@private
selected = True
Rationale: The 'def' statement
How about this: Email responses/ideas to me directly, I'll summarize
them and post the result.
Guido van Rossum wrote:
> I've been thinking about this too, and I think it's reasonable to let
> the metaclass provide the dict to be used as locals. This is easier
> when the metaclass is given in the
I've been thinking about this too, and I think it's reasonable to let
the metaclass provide the dict to be used as locals. This is easier
when the metaclass is given in the class header, e.g. by way of a base
class, or through the default metaclass. Although the default default
metaclass could of c
Another mini-brainstorm, which is how to represent PJE's 'defop' syntax
without adding any keywords:
Alternative 1. Omitting the function name in 'def' statements.
Let us define the behavior of the 'def' statement as follows:
The function name in the 'def' statement is optional - if the
fu
Tim Hochberg wrote:
> Talin wrote:
>
>> Phillip J. Eby wrote:
>>
>>> At 09:59 AM 12/5/2006 -0600, Guido van Rossum wrote:
>>>
My point is that an interface can *document* (at least in English) a
"contract" about the invariants between operations. While I'm not into
enf
I'd like to see metaclasses have additional capabilities in Py3K, and
one thing I'd like is for metaclasses to be able to have access to the
order of declarations within a class.
If I understand correctly, in the current Python a class definition is
essentially a suite with ordinary local varia
21 matches
Mail list logo
