Mailing List Archive: Python: Dev

Adding types.build_class for 3.3

1 2

View All

Index | Next | Previous | View Threaded

ncoghlan at gmail

May 7, 2012, 4:10 AM

Post #1 of 37 (758 views)
Permalink

Adding types.build_class for 3.3

A while back I pointed out that there's no easy PEP 3115 compliant way
to dynamically create a class (finding the right metaclass, calling
__prepare__, etc).

I initially proposed providing this as operator.build_class, and
Daniel Urban created a patch that implements that API
(http://bugs.python.org/issue14588).

However, in starting to write the documentation for the new API, I
realised that the operator module really isn't the right home for the
functionality.

Instead, I'm now thinking we should add a _types C extension module
and expose the new function as types.build_class(). I don't want to
add an entire new module just for this feature, and the types module
seems like an appropriate home for it.

Thoughts?

Regards,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

g.brandl at gmx

May 7, 2012, 4:54 AM

Post #2 of 37 (750 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On 05/07/2012 01:10 PM, Nick Coghlan wrote:
> A while back I pointed out that there's no easy PEP 3115 compliant way
> to dynamically create a class (finding the right metaclass, calling
> __prepare__, etc).
>
> I initially proposed providing this as operator.build_class, and
> Daniel Urban created a patch that implements that API
> (http://bugs.python.org/issue14588).
>
> However, in starting to write the documentation for the new API, I
> realised that the operator module really isn't the right home for the
> functionality.
>
> Instead, I'm now thinking we should add a _types C extension module
> and expose the new function as types.build_class(). I don't want to
> add an entire new module just for this feature, and the types module
> seems like an appropriate home for it.

Yay for being able to get rid of the stupidities the types module goes
through to get at its types (i.e. if we start having a C module, the
whole contents can go there.)

As for build_class: at the moment the types module really only has types,
and to add build_class there is just about as weird as in operator IMO.

cheers,
Georg

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

benjamin at python

May 7, 2012, 4:56 AM

Post #3 of 37 (751 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

2012/5/7 Nick Coghlan <ncoghlan [at] gmail>:
> A while back I pointed out that there's no easy PEP 3115 compliant way
> to dynamically create a class (finding the right metaclass, calling
> __prepare__, etc).
>
> I initially proposed providing this as operator.build_class, and
> Daniel Urban created a patch that implements that API
> (http://bugs.python.org/issue14588).
>
> However, in starting to write the documentation for the new API, I
> realised that the operator module really isn't the right home for the
> functionality.
>
> Instead, I'm now thinking we should add a _types C extension module
> and expose the new function as types.build_class(). I don't want to
> add an entire new module just for this feature, and the types module
> seems like an appropriate home for it.

Actually, there used to be a _types C module before we figured out
that all the types could be extracted in Python. :)

Maybe you could make it a static or class method of type?

--
Regards,
Benjamin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

May 7, 2012, 5:15 AM

Post #4 of 37 (751 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Mon, May 7, 2012 at 9:54 PM, Georg Brandl <g.brandl [at] gmx> wrote:
> As for build_class: at the moment the types module really only has types,
> and to add build_class there is just about as weird as in operator IMO.

Oh no, types is definitely less weird - at least it's related to the
type system, whereas the operator module is about operator syntax
(attrgetter, itemgetter and index are at least related to the dot
operator and subscripting syntax)

Benjamin's suggestion of a class method on type may be a good one,
though. Then the invocation (using all arguments) would be:

mcl.build_class(name, bases, keywords, exec_body)

Works for me, so unless someone else can see a problem I've missed,
we'll go with that.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

g.brandl at gmx

May 7, 2012, 5:23 AM

Post #5 of 37 (751 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On 05/07/2012 02:15 PM, Nick Coghlan wrote:
> On Mon, May 7, 2012 at 9:54 PM, Georg Brandl <g.brandl [at] gmx> wrote:
>> As for build_class: at the moment the types module really only has types,
>> and to add build_class there is just about as weird as in operator IMO.
>
> Oh no, types is definitely less weird - at least it's related to the
> type system, whereas the operator module is about operator syntax
> (attrgetter, itemgetter and index are at least related to the dot
> operator and subscripting syntax)
>
> Benjamin's suggestion of a class method on type may be a good one,
> though. Then the invocation (using all arguments) would be:
>
> mcl.build_class(name, bases, keywords, exec_body)
>
> Works for me, so unless someone else can see a problem I've missed,
> we'll go with that.

Works for me.

Georg

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

hrvoje.niksic at avl

May 7, 2012, 6:42 AM

Post #6 of 37 (745 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On 05/07/2012 02:15 PM, Nick Coghlan wrote:
> Benjamin's suggestion of a class method on type may be a good one,
> though. Then the invocation (using all arguments) would be:
>
> mcl.build_class(name, bases, keywords, exec_body)
>
> Works for me, so unless someone else can see a problem I've missed,
> we'll go with that.

Note that to call mcl.build_class, you have to find a metaclass that
works for bases, which is the job of build_class. Putting it as a
function in the operator module seems like a better solution.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

greg.ewing at canterbury

May 7, 2012, 3:59 PM

Post #7 of 37 (747 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

Nick Coghlan wrote:

> Instead, I'm now thinking we should add a _types C extension module
> and expose the new function as types.build_class(). I don't want to
> add an entire new module just for this feature, and the types module
> seems like an appropriate home for it.

Dunno. Currently the only thing the types module contains is
types. A function would seem a bit out of place there.

I don't think there's too much wrong with putting it in the
operators module -- it's a function doing something that is
otherwise expressed by special syntax.

--
Greg
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

May 7, 2012, 4:15 PM

Post #8 of 37 (745 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

For those suggesting the operator module is actually a good choice, there's
no way to add this function without making major changes to the module
description (go read it - I only realised the problem when I went to add
the docs). It's a bad fit (*much* worse than types or a class method)

--
Sent from my phone, thus the relative brevity :)
On May 8, 2012 9:01 AM, "Greg Ewing" <greg.ewing [at] canterbury> wrote:

> Nick Coghlan wrote:
>
> Instead, I'm now thinking we should add a _types C extension module
>> and expose the new function as types.build_class(). I don't want to
>> add an entire new module just for this feature, and the types module
>> seems like an appropriate home for it.
>>
>
> Dunno. Currently the only thing the types module contains is
> types. A function would seem a bit out of place there.
>
> I don't think there's too much wrong with putting it in the
> operators module -- it's a function doing something that is
> otherwise expressed by special syntax.
>
> --
> Greg
> ______________________________**_________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> ncoghlan%40gmail.com<http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com>
>

ericsnowcurrently at gmail

May 7, 2012, 5:57 PM

Post #9 of 37 (743 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Mon, May 7, 2012 at 6:15 AM, Nick Coghlan <ncoghlan [at] gmail> wrote:
> On Mon, May 7, 2012 at 9:54 PM, Georg Brandl <g.brandl [at] gmx> wrote:
>> As for build_class: at the moment the types module really only has types,
>> and to add build_class there is just about as weird as in operator IMO.
>
> Oh no, types is definitely less weird - at least it's related to the
> type system, whereas the operator module is about operator syntax
> (attrgetter, itemgetter and index are at least related to the dot
> operator and subscripting syntax)
>
> Benjamin's suggestion of a class method on type may be a good one,
> though. Then the invocation (using all arguments) would be:
>
> mcl.build_class(name, bases, keywords, exec_body)
>
> Works for me, so unless someone else can see a problem I've missed,
> we'll go with that.

+1

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

May 7, 2012, 6:59 PM

Post #10 of 37 (741 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Mon, May 7, 2012 at 11:42 PM, Hrvoje Niksic <hrvoje.niksic [at] avl> wrote:
> On 05/07/2012 02:15 PM, Nick Coghlan wrote:
>>
>> Benjamin's suggestion of a class method on type may be a good one,
>> though. Then the invocation (using all arguments) would be:
>>
>> mcl.build_class(name, bases, keywords, exec_body)
>>
>> Works for me, so unless someone else can see a problem I've missed,
>> we'll go with that.
>
>
> Note that to call mcl.build_class, you have to find a metaclass that works
> for bases, which is the job of build_class. Putting it as a function in the
> operator module seems like a better solution.

No, the "mcl" in the call is just the designated metaclass - the
*actual* metaclass of the resulting class definition may be something
different. That's why this is a separate method from mcl.__new__.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

May 8, 2012, 9:50 AM

Post #11 of 37 (738 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On May 08, 2012, at 11:59 AM, Nick Coghlan wrote:

>No, the "mcl" in the call is just the designated metaclass - the
>*actual* metaclass of the resulting class definition may be something
>different. That's why this is a separate method from mcl.__new__.

I'm not completely sold on adding a class method to type, but I acknowledge
that it's a convenient place to put it. Still, it doesn't feel particularly
more right than adding it to say, the operator module. I don't think we have
any class methods on type yet, so this would be setting a precedence that we
should be sure we want to establish.

Cheers,
-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

tjreedy at udel

May 8, 2012, 2:07 PM

Post #12 of 37 (737 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On 5/8/2012 12:50 PM, Barry Warsaw wrote:
> On May 08, 2012, at 11:59 AM, Nick Coghlan wrote:
>
>> No, the "mcl" in the call is just the designated metaclass - the
>> *actual* metaclass of the resulting class definition may be something
>> different. That's why this is a separate method from mcl.__new__.
>
> I'm not completely sold on adding a class method to type, but I acknowledge
> that it's a convenient place to put it. Still, it doesn't feel particularly
> more right than adding it to say, the operator module.

The operator module strikes me as completely wrong. To me, a function
that creates classes (types) belongs either in the types module or
attached to the type metaclass. Attaching an alternate constructor to
type as a class method would be analogous to attaching an alternate dict
constructor to dict (.fromkeys).

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

tseaver at palladion

May 8, 2012, 3:37 PM

Post #13 of 37 (729 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 05/07/2012 09:59 PM, Nick Coghlan wrote:
> On Mon, May 7, 2012 at 11:42 PM, Hrvoje Niksic <hrvoje.niksic [at] avl>
> wrote:
>> On 05/07/2012 02:15 PM, Nick Coghlan wrote:
>>>
>>> Benjamin's suggestion of a class method on type may be a good
>>> one, though. Then the invocation (using all arguments) would be:
>>>
>>> mcl.build_class(name, bases, keywords, exec_body)
>>>
>>> Works for me, so unless someone else can see a problem I've
>>> missed, we'll go with that.
>>
>>
>> Note that to call mcl.build_class, you have to find a metaclass that
>> works for bases, which is the job of build_class. Putting it as a
>> function in the operator module seems like a better solution.
>
> No, the "mcl" in the call is just the designated metaclass - the
> *actual* metaclass of the resulting class definition may be something
> different. That's why this is a separate method from mcl.__new__.

Why not make it a static method, if there is no notion of a useful 'cls'
argument?

Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tseaver [at] palladion
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+poCQACgkQ+gerLs4ltQ6IUwCfckUDbCCFjRPcFtvQmTXUcGuv
8RYAoKzry9l0xB7G+I0fIBqAp+3DJTdc
=3kdb
-----END PGP SIGNATURE-----

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

May 8, 2012, 6:10 PM

Post #14 of 37 (721 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Wed, May 9, 2012 at 8:37 AM, Tres Seaver <tseaver [at] palladion> wrote:
>> No, the "mcl" in the call is just the designated metaclass - the
>> *actual* metaclass of the resulting class definition may be something
>> different. That's why this is a separate method from mcl.__new__.
>
> Why not make it a static method, if there is no notion of a useful 'cls'
> argument?

We need the explicitly declared metaclass as well as the bases in
order to determine the correct metaclass.

As a static method, the invocation would look like:

type.build_class(mcl, bases, keywords, exec_body)

Since mcl will always be an instance of type in 3.x (due to all
classes being subtypes of object), it makes more sense to just make it
a class method and invoke the method on the declared metaclass:

mcl.build_class(bases, keywords, exec_body)

The following assertion *does not* hold reliably:

cls = mcl.build_class(bases, keywords, exec_body)
assert type(cls) == mcl # Not guaranteed

Instead, the invariant that holds is the weaker assertion:

cls = mcl.build_class(bases, keywords, exec_body)
assert isinstance(cls, mcl)

This is due to the fact that one of the bases may specify that the
actual metaclass is a subtype of mcl rather than mcl itself.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

urban.dani+py at gmail

May 8, 2012, 11:37 PM

Post #15 of 37 (722 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan <ncoghlan [at] gmail> wrote:
> On Wed, May 9, 2012 at 8:37 AM, Tres Seaver <tseaver [at] palladion> wrote:
>>> No, the "mcl" in the call is just the designated metaclass - the
>>> *actual* metaclass of the resulting class definition may be something
>>> different. That's why this is a separate method from mcl.__new__.
>>
>> Why not make it a static method, if there is no notion of a useful 'cls'
>> argument?
>
> We need the explicitly declared metaclass as well as the bases in
> order to determine the correct metaclass.

Note, that the current patch (at http://bugs.python.org/issue14588)
obtains the explicitly declared metaclass from the keywords dict
(exactly like the class statement).

> As a static method, the invocation would look like:
>
> Â Â type.build_class(mcl, bases, keywords, exec_body)

So I think, that in theory, this static method could work exactly like
the operator.build_class function in the patch: type.build_class(name,
bases, kwds, exec_body) (it doesn't need the mcls in a separate
argument, it is in kwds).

> Since mcl will always be an instance of type in 3.x (due to all
> classes being subtypes of object), it makes more sense to just make it
> a class method and invoke the method on the declared metaclass:
>
> Â Â mcl.build_class(bases, keywords, exec_body)

We could do that, but "mcl will always be an instance of type in 3.x"
is not strictly true: an arbitrary callable is still allowed as a
metaclass in a class statement, so I think the build_class function
should support it too.

> The following assertion *does not* hold reliably:
>
> Â Â cls = mcl.build_class(bases, keywords, exec_body)
> Â Â assert type(cls) == mcl # Not guaranteed

Right.

> Instead, the invariant that holds is the weaker assertion:
>
> Â Â cls = mcl.build_class(bases, keywords, exec_body)
> Â Â assert isinstance(cls, mcl)

But if mcl is an arbitrary callable, this is also not always true (of
course, then the invocation above wouldn't work, but with a class
statement we could still create such "classes":

>>> def f(mcls, name, bases):
... return 0
...
>>> class C(metaclass=f):
... pass
...
>>> C
0

Daniel
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

May 9, 2012, 12:20 AM

Post #16 of 37 (721 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Wed, May 9, 2012 at 4:37 PM, Daniel Urban <urban.dani+py [at] gmail> wrote:
> On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan <ncoghlan [at] gmail> wrote:
>> We need the explicitly declared metaclass as well as the bases in
>> order to determine the correct metaclass.
>
> Note, that the current patch (at http://bugs.python.org/issue14588)
> obtains the explicitly declared metaclass from the keywords dict
> (exactly like the class statement).

Ah, good point. In that case, consider me convinced: static method it
is. It can join mro() as the second non-underscore method defined on
type().

Regards,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mark at hotpy

May 9, 2012, 12:57 AM

Post #17 of 37 (720 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

Nick Coghlan wrote:
> On Wed, May 9, 2012 at 4:37 PM, Daniel Urban <urban.dani+py [at] gmail> wrote:
>> On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan <ncoghlan [at] gmail> wrote:
>>> We need the explicitly declared metaclass as well as the bases in
>>> order to determine the correct metaclass.
>> Note, that the current patch (at http://bugs.python.org/issue14588)
>> obtains the explicitly declared metaclass from the keywords dict
>> (exactly like the class statement).
>
> Ah, good point. In that case, consider me convinced: static method it
> is. It can join mro() as the second non-underscore method defined on
> type().
>

Be careful adding methods to type. Because type is its own metaclass
descriptors can appear to add strangely:

int.mro()

[<class 'int'>, <class 'object'>]

type.mro()

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: descriptor 'mro' of 'type' object needs an argument

As a consequence of this, making build_class either a class method or a
static method will cause a direct call to type.build_class() to fail as
neither class method nor static method are callable.

Cheers,
Mark.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

May 9, 2012, 1:21 AM

Post #18 of 37 (719 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Wed, May 9, 2012 at 5:57 PM, Mark Shannon <mark [at] hotpy> wrote:
> As a consequence of this, making build_class either a class method or a
> static method will cause a direct call to type.build_class() to fail as
> neither class method nor static method are callable.

We'll make sure it *behaves* like a static method, even if it's
technically something else under the hood.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

mark at hotpy

May 9, 2012, 1:29 AM

Post #19 of 37 (718 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

Nick Coghlan wrote:
> On Wed, May 9, 2012 at 5:57 PM, Mark Shannon <mark [at] hotpy> wrote:
>> As a consequence of this, making build_class either a class method or a
>> static method will cause a direct call to type.build_class() to fail as
>> neither class method nor static method are callable.
>
> We'll make sure it *behaves* like a static method, even if it's
> technically something else under the hood.

What I am saying is that you *don't* want it to behave like a static
method, you want it to behave like a builtin-function.

Cheers,
Mark.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

steve at pearwood

May 9, 2012, 2:05 AM

Post #20 of 37 (718 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Wed, May 09, 2012 at 08:57:55AM +0100, Mark Shannon wrote:

> As a consequence of this, making build_class either a class method or a
> static method will cause a direct call to type.build_class() to fail as
> neither class method nor static method are callable.

This might be a good reason to make them callable, especially
staticmethod. I understand that at the language summit, this was
considered a good idea:

http://python.6.n6.nabble.com/Callable-non-descriptor-class-attributes-td1884829.html

It certainly seems long overdue: confusion due to staticmethods
not being callable go back a long time:

http://stackoverflow.com/questions/3932948/
http://grokbase.com/t/python/python-list/11bhhtv95y/staticmethod-makes-my-brain-hurt
http://mail.python.org/pipermail/python-list/2004-August/272593.html

--
Steven
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ericsnowcurrently at gmail

May 9, 2012, 7:32 AM

Post #21 of 37 (713 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Wed, May 9, 2012 at 3:05 AM, Steven D'Aprano <steve [at] pearwood> wrote:
> I understand that at the language summit, this was
> considered a good idea:
>
> http://python.6.n6.nabble.com/Callable-non-descriptor-class-attributes-td1884829.html

<aside>FYI, this was at the 2011 language summit</aside>

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

barry at python

May 9, 2012, 9:21 AM

Post #22 of 37 (710 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On May 09, 2012, at 05:20 PM, Nick Coghlan wrote:

>Ah, good point. In that case, consider me convinced: static method it
>is. It can join mro() as the second non-underscore method defined on
>type().

+1

If I may dip into the bikeshed paint once more. I think it would be useful to
establish a naming convention for alternative constructors implemented as
{static,class}methods. I don't like `build_class()` much. Would you be
opposed to `type.new()`?

-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

brett at python

May 9, 2012, 12:18 PM

Post #23 of 37 (701 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Wed, May 9, 2012 at 12:21 PM, Barry Warsaw <barry [at] python> wrote:

> On May 09, 2012, at 05:20 PM, Nick Coghlan wrote:
>
> >Ah, good point. In that case, consider me convinced: static method it
> >is. It can join mro() as the second non-underscore method defined on
> >type().
>
> +1
>
> If I may dip into the bikeshed paint once more. I think it would be
> useful to
> establish a naming convention for alternative constructors implemented as
> {static,class}methods. I don't like `build_class()` much. Would you be
> opposed to `type.new()`?

Depends on how far you want this new term to go since "new" is somewhat
overloaded thanks to __new__(). I personally like create().

ncoghlan at gmail

May 9, 2012, 3:14 PM

Post #24 of 37 (699 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

Given that the statement form is referred to as a "class definition", and
this is the dynamic equivalent, I'm inclined to go with "type.define()".
Dynamic type definition is more consistent with existing terminology than
dynamic type creation.

--
Sent from my phone, thus the relative brevity :)

rdmurray at bitdance

May 9, 2012, 4:44 PM

Post #25 of 37 (692 views)
Permalink

Re: Adding types.build_class for 3.3 [In reply to]

On Thu, 10 May 2012 08:14:55 +1000, Nick Coghlan <ncoghlan [at] gmail> wrote:
> Given that the statement form is referred to as a "class definition", and
> this is the dynamic equivalent, I'm inclined to go with "type.define()".
> Dynamic type definition is more consistent with existing terminology than
> dynamic type creation.

Yeah, but that's the statement form. I think of the characters in the
.py file as the definition. If I'm creating a class dynamically...I'm
creating(*) it, not defining it.

I don't think it's a big deal, though. Either word will work.

--David

(*) Actually, come to think of it, I probably refer to it as
"constructing" the class, rather than creating or defining it.
It's the type equivalent of constructing an instance, perhaps?
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads