Mailing List Archive: Python: Dev

Adding types.build_class for 3.3

1 2

View All

Index | Next | Previous | View Threaded

greg.ewing at canterbury

May 9, 2012, 5:03 PM

Post #26 of 37 (163 views)
Permalink

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

Nick Coghlan wrote:
> In that case, consider me convinced: static method it
> is.

-0.93. Static methods are generally unpythonic, IMO.

Python is not Java -- we have modules. Something should
only go in a class namespace if it somehow relates to
that particular class, and other classes could might
implement it differently. That's not the case with
build_class().

--
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 9, 2012, 6:45 PM

Post #27 of 37 (163 views)
Permalink

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

On Thu, May 10, 2012 at 10:03 AM, Greg Ewing
<greg.ewing [at] canterbury> wrote:
> Python is not Java -- we have modules. Something should
> only go in a class namespace if it somehow relates to
> that particular class, and other classes could might
> implement it differently. That's not the case with
> build_class().

Not true - you *will* get a type instance out of any sane call to
type.define(). Technically, you could probably declare your metaclass
such that you get a non-type object instead (just as you can with a
class definition), but that means you're really just using an insanely
convoluted way to make an ordinary function call. If you didn't want
to invoke the full PEP 3115 find metaclass/prepare namespace/execute
body/call metaclass dance, why would you be calling type.define
instead of just calling the metaclass directly?

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 10, 2012, 1:11 AM

Post #28 of 37 (161 views)
Permalink

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

Nick Coghlan wrote:
> On Thu, May 10, 2012 at 10:03 AM, Greg Ewing
> <greg.ewing [at] canterbury> wrote:
>> Python is not Java -- we have modules. Something should
>> only go in a class namespace if it somehow relates to
>> that particular class, and other classes could might
>> implement it differently. That's not the case with
>> build_class().

+1

>
> Not true - you *will* get a type instance out of any sane call to
> type.define(). Technically, you could probably declare your metaclass
> such that you get a non-type object instead (just as you can with a
> class definition), but that means you're really just using an insanely
> convoluted way to make an ordinary function call. If you didn't want
> to invoke the full PEP 3115 find metaclass/prepare namespace/execute
> body/call metaclass dance, why would you be calling type.define
> instead of just calling the metaclass directly?

By attaching the 'define' object to type, then the descriptor protocol
causes problems if 'define' is a desriptor since type is its own
metaclass. If it were a builtin-function, then there would be no problem.

A module-level builtin-function is more likely to be correct and seems
to me to be more Pythonic. Not that I'm a good judge of Pythonicness :)

Finally, could you remind me how the proposed type.define differs from
builtins.__build_class__?
I can't see any difference (apart from parameter ordering and the extra
name parameter in builtins.__build_class__).

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 10, 2012, 1:27 AM

Post #29 of 37 (161 views)
Permalink

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

On Thu, May 10, 2012 at 6:11 PM, Mark Shannon <mark [at] hotpy> wrote:
> Finally, could you remind me how the proposed type.define differs from
> builtins.__build_class__?
> I can't see any difference (apart from parameter ordering and the extra name
> parameter in builtins.__build_class__).

It's the officially supported version of that API - the current
version is solely a CPython implementation detail. The main change is
moving exec_body to the end and making it optional, thus bringing the
interface more in line with calling a metaclass directly. The name
parameter is actually still there, I just forgot to include in the
examples in the thread.

You'll find there's no mention of __build_class__ in the language or
library references, thus there's currently no official way to
programmatically define a new type in a way that complies with PEP
3115.

(This is explained in the tracker issue and the previous thread that
proposed the name operator.build_class)

I prefer type.define(), but if the descriptor protocol does cause
problems (and making static methods callable doesn't fix them), then
we'll move it somewhere else (probably types.define() with a new
_types module).

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 10, 2012, 2:51 AM

Post #30 of 37 (161 views)
Permalink

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

Nick Coghlan wrote:
> On Thu, May 10, 2012 at 6:11 PM, Mark Shannon <mark [at] hotpy> wrote:
>> Finally, could you remind me how the proposed type.define differs from
>> builtins.__build_class__?
>> I can't see any difference (apart from parameter ordering and the extra name
>> parameter in builtins.__build_class__).
>
> It's the officially supported version of that API - the current
> version is solely a CPython implementation detail. The main change is
> moving exec_body to the end and making it optional, thus bringing the
> interface more in line with calling a metaclass directly. The name
> parameter is actually still there, I just forgot to include in the
> examples in the thread.
>
> You'll find there's no mention of __build_class__ in the language or
> library references, thus there's currently no official way to
> programmatically define a new type in a way that complies with PEP
> 3115.
>
> (This is explained in the tracker issue and the previous thread that
> proposed the name operator.build_class)

>
> I prefer type.define(), but if the descriptor protocol does cause
> problems (and making static methods callable doesn't fix them), then
> we'll move it somewhere else (probably types.define() with a new
> _types module).

The problem with any non-overriding descriptor bound to type is that
when accessed as type.define it acts as a descriptor, but when accessed
from any other class, say int.define it acts as a non-overriding
meta-descriptor; c.f. type.mro() vs int.mro()

To avoid this problem, type.define needs to be an overriding descriptor
such as a property (a PyGetSetDef in C).
Alternatively, just make 'define' a non-descriptor.
It would unusual (unique?) to have a builtin-function (rather than a
method-descriptor) bound to a class, but I can't see any fundamental
reason not to.

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 10, 2012, 3:19 AM

Post #31 of 37 (160 views)
Permalink

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

On Thu, May 10, 2012 at 7:51 PM, Mark Shannon <mark [at] hotpy> wrote:
> To avoid this problem, type.define needs to be an overriding descriptor
> such as a property (a PyGetSetDef in C).
> Alternatively, just make 'define' a non-descriptor.
> It would unusual (unique?) to have a builtin-function (rather than a
> method-descriptor) bound to a class, but I can't see any fundamental reason
> not to.

Oh, I see what you mean now. I hadn't fully thought through the
implications of the static method being accessible through all
instances of type, and that really doesn't seem like a good outcome.
Exposing it through the types module as an ordinary builtin function
is starting to sound a lot more attractive at this point.

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

greg.ewing at canterbury

May 10, 2012, 4:26 AM

Post #32 of 37 (160 views)
Permalink

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

Nick Coghlan wrote:
> On Thu, May 10, 2012 at 10:03 AM, Greg Ewing
> <greg.ewing [at] canterbury> wrote:
>
>>Something should
>>only go in a class namespace if it somehow relates to
>>that particular class, and other classes could might
>>implement it differently. That's not the case with
>>build_class().
>
> Not true - you *will* get a type instance out of any sane call to
> type.define().

You must have misunderstood me, because this doesn't
relate to the point I was making at all.

What I'm trying to say is that I don't see the justification
for making build_class() a static method rather than a
plain module-level function.

To my way of thinking, static methods are very rarely
justified in Python. The only argument so far in this
case seems to be "we can't make up our minds where else
to put it", which is rather lame.

A stronger argument would be if there were cases where
you wanted to define a subclass of type that implemented
build_class differently. But how would it get called, if
everyone who uses build_class invokes it using
'type.build_class()'?

--
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

barry at python

May 10, 2012, 10:31 AM

Post #33 of 37 (153 views)
Permalink

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

On May 09, 2012, at 07:44 PM, R. David Murray wrote:

>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.

That's exactly how I think about it too.

>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?

If, as Nick proposes in a different message, it actually does make better
sense to put this as a module-level function, then putting `class` in the name
makes sense. types.{new,create,build,construct}_class() works for me, in
roughly that order.

-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

ncoghlan at gmail

May 10, 2012, 5:56 PM

Post #34 of 37 (153 views)
Permalink

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

On Fri, May 11, 2012 at 3:31 AM, Barry Warsaw <barry [at] python> wrote:
> On May 09, 2012, at 07:44 PM, R. David Murray wrote:
>>(*) 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?
>
> If, as Nick proposes in a different message, it actually does make better
> sense to put this as a module-level function, then putting `class` in the name
> makes sense. types.{new,create,build,construct}_class() works for me, in
> roughly that order.

Yeah, as a result of the discussion in this thread, and considering
the parallel with "imp.new_module()", I'm going to update the tracker
issue to propose the addition of "types.new_class()" as the dynamic
API for the PEP 3115 metaclass protocol.

The question now moves to the implementation strategy - whether we
redirect to the C machinery as originally proposed (either via
__build_class__ or a new _types module) or just reimplement the
algorithm in pure Python. The latter is actually quite an appealing
concept, since it becomes a cross-check on the native C version.

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 10, 2012, 11:21 PM

Post #35 of 37 (149 views)
Permalink

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

Nick Coghlan wrote:
> On Fri, May 11, 2012 at 3:31 AM, Barry Warsaw <barry [at] python> wrote:
>> On May 09, 2012, at 07:44 PM, R. David Murray wrote:
>>> (*) 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?
>> If, as Nick proposes in a different message, it actually does make better
>> sense to put this as a module-level function, then putting `class` in the name
>> makes sense. types.{new,create,build,construct}_class() works for me, in
>> roughly that order.
>
> Yeah, as a result of the discussion in this thread, and considering
> the parallel with "imp.new_module()", I'm going to update the tracker
> issue to propose the addition of "types.new_class()" as the dynamic
> API for the PEP 3115 metaclass protocol.
>
> The question now moves to the implementation strategy - whether we
> redirect to the C machinery as originally proposed (either via
> __build_class__ or a new _types module) or just reimplement the
> algorithm in pure Python. The latter is actually quite an appealing
> concept, since it becomes a cross-check on the native C version.

+1 to a pure Python version.

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

tjreedy at udel

May 11, 2012, 7:16 AM

Post #36 of 37 (146 views)
Permalink

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

On 5/11/2012 2:21 AM, Mark Shannon wrote:
> Nick Coghlan wrote:

>> The question now moves to the implementation strategy - whether we
>> redirect to the C machinery as originally proposed (either via
>> __build_class__ or a new _types module) or just reimplement the
>> algorithm in pure Python. The latter is actually quite an appealing
>> concept, since it becomes a cross-check on the native C version.

I assume types.new_class would eventually call type(). This would make
it available to any implementation with a conforming type().

> +1 to a pure Python version.

Since new_class would be used rarely and not in inner loops, and (if I
understand) should mostly contain branching logic rather than looping,
speed hardly seems an issue.

---
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

rdmurray at bitdance

May 11, 2012, 8:36 AM

Post #37 of 37 (145 views)
Permalink

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

On Fri, 11 May 2012 10:16:42 -0400, Terry Reedy <tjreedy [at] udel> wrote:
> On 5/11/2012 2:21 AM, Mark Shannon wrote:
> > +1 to a pure Python version.
>
> Since new_class would be used rarely and not in inner loops, and (if I
> understand) should mostly contain branching logic rather than looping,
> speed hardly seems an issue.

Well, actually, the proposed new email policy is doing dynamic class
construction for any header accessed by the application, which could
potentially be every header in every message processed by an application
if refold_source is set true. That's not quite an "inner loop", but it
isn't an outer one either.

That said, the header parsing logic that is also invoked by the process
of returning a header under the new policy is going to outweigh the
class construction overhead, I'm pretty sure.

--David
_______________________________________________
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