Re: [Python-Dev] Adding types.build_class for 3.3
Nick Coghlan wrote: On Thu, May 10, 2012 at 10:03 AM, Greg Ewing 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Thu, May 10, 2012 at 6:11 PM, Mark Shannon 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 | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Thu, 10 May 2012 11:33:14 +1000 Nick Coghlan wrote: > > The original concern (that sys.implementation may differ in length > across implementations) has been eliminated by moving all > implementation specific values into sys.implementation.metadata. Uh. It's scary the kind of things people sometimes come up with :-) sys.implementation.metadata looks like a completely over-engineered concept. Please, let's just make sys.implementation a dict and stop bothering about ordering and iterability. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
Nick Coghlan wrote: On Thu, May 10, 2012 at 6:11 PM, Mark Shannon 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Thu, May 10, 2012 at 7:51 PM, Mark Shannon 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 | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou wrote: > On Thu, 10 May 2012 11:33:14 +1000 > Nick Coghlan wrote: >> >> The original concern (that sys.implementation may differ in length >> across implementations) has been eliminated by moving all >> implementation specific values into sys.implementation.metadata. > > Uh. It's scary the kind of things people sometimes come up with :-) > > sys.implementation.metadata looks like a completely over-engineered > concept. Please, let's just make sys.implementation a dict and stop > bothering about ordering and iterability. Aye. Add a rule that all implementation specific (i.e. not defined in the PEP) keys must be prefixed with an underscore and I'm sold. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
Nick Coghlan wrote: On Thu, May 10, 2012 at 10:03 AM, Greg Ewing 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Allow use of sphinx-autodoc in the standard library documentation?
On Thu, 10 May 2012 15:02:20 +1000, Nick Coghlan wrote: > So, given the advantages of autodoc, is there a concrete reason why we > can't use it for the documentation of *new* standard library modules? Yes. Our reason is that docstrings should be relatively lightweight, and that the sphinx docs should be the more expansive version of the documentation. Yes, this creates a double-maintenance burden, and the two sometimes slip of of sync. But it is a long-standing rule and will doubtless require considerable bikeshedding if we want to change it :) --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On 10.05.2012 10:57, Antoine Pitrou wrote: > On Thu, 10 May 2012 11:33:14 +1000 > Nick Coghlan wrote: >> >> The original concern (that sys.implementation may differ in length >> across implementations) has been eliminated by moving all >> implementation specific values into sys.implementation.metadata. > > Uh. It's scary the kind of things people sometimes come up with :-) .oO( Namespaception ) > sys.implementation.metadata looks like a completely over-engineered > concept. Please, let's just make sys.implementation a dict and stop > bothering about ordering and iterability. Agreed. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Allow use of sphinx-autodoc in the standard library documentation?
On 10.05.2012 07:02, Nick Coghlan wrote: > One of the requirements for acceptance of PEP 3144 if the provision of > a reStructuredText API reference. > > The current plan for dealing with that is to use Spinx apidoc to > create a skeleton, and then capture the rewritten ReST produced by > autodoc. > > However, it occurs to me that the module reference could actually > *use* autodoc, with additional prose added to supplement the > docstrings, rather than completely replacing them. > > I'd initially dismissed this idea out of hand, but recently realised I > didn't have any especially strong arguments against it (and there are > all the usual "avoid double-keying data" arguments in favour). > > So, given the advantages of autodoc, is there a concrete reason why we > can't use it for the documentation of *new* standard library modules? The one reason that prevented me from ever proposing this is that to do this, you have to build the docs with exactly the Python you want the documentation for. This can create unpleasant dependencies for e.g. distributions, and also for developers who cannot build the docs without first building Python, which can be a hassle, especially under Windows. But of course we want people to build the docs before committing... The other issue is the extensiveness of the docstrings vs. separate docs. So far, the latter have always been more comprehensive than the docstrings, which works nicely for me (although crucial info is sometimes missing in the docstring). This difference can be kept, to a degree, even with autodoc, by putting additional content into the autodoc directive, but that renders one big autodoc advantage moot: having the documentation in one place only. Even worse, if someone changes the docstring, the addendum in the rst file may become wrong/obsolete/incomprehensible. cheers, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On 5/10/2012 10:42 AM, Georg Brandl wrote: On 10.05.2012 10:57, Antoine Pitrou wrote: On Thu, 10 May 2012 11:33:14 +1000 Nick Coghlan wrote: The original concern (that sys.implementation may differ in length across implementations) has been eliminated by moving all implementation specific values into sys.implementation.metadata. Uh. It's scary the kind of things people sometimes come up with :-) .oO( Namespaception ) sys.implementation.metadata looks like a completely over-engineered concept. Please, let's just make sys.implementation a dict and stop bothering about ordering and iterability. Thank you for cutting through the knot. Agreed. Ditto. Iterability is good and should be part of all python collections. People who want a sorted representation should just use sorted(d.items) as with other sortable mappings. Nick's idea of prefixing local implementation keys with '_' would nicely group them together on sorted displays. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On 5/10/2012 1:40 AM, Nick Coghlan wrote: > Unordered types can be a PITA for testing, for display and for generic > serialisation, so I definitely want to see a PEP before we add a new > one that basically has its sole reason for existence being "you can > iterate over and index the field values in a namedtuple". > I could use those same arguments (testing, display, and generic serialization) as reasons /against/ using an ordered type (when it's not the intent of the author that it be ordered). That is: - Testing: This is an attractive nuisance because adding fields later can break the tests if the author of the type had no intent on the ordering being guaranteed (or the number of fields). - Display: If the author of the type didn't intend on the ordering being guaranteed, then the display could become nonsense when changing versions (e.g., upgrading a 3rd-party library). - Generic Serialization: Again, if the author didn't plan for that, then they could add additional fields or re-arrange them in a way that makes naive serialization give incorrect instances. The point is that the author of the type can't protect you from these mistakes if a namedtuple is used. The only tool the author of the type has at their disposal to warn you of your ways is documentation. If the type doesn't support iteration or indexing, then you are forced to do it right, because it's the only way that works. Furthermore, what is wrong with a repr that yields a dict-like string "record(a=1, b=2, c=3)" with regard to testing and display? -- Scott Dial [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On May 09, 2012, at 07:44 PM, R. David Murray wrote:
>On Thu, 10 May 2012 08:14:55 +1000, Nick Coghlan 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Point of building without threads?
Antoine Pitrou wrote: > On Wed, 9 May 2012 11:26:29 +0200 > Stefan Krah wrote: > > Antoine Pitrou wrote: > > > > _decimal is about 12% faster without threads, because the expensive > > > > thread local context can be disabled. > > > > > > If you cached the last thread id along with the corresponding context, > > > perhaps it could speed things up in most scenarios? > > > > Nice. This reduces the speed difference to about 4%! > > Note that you don't need the actual thread id, the Python thread state > is sufficient: PyThreadState_GET should be a simply variable lookup in > release builds. I've tried both ways now and the speed gain is roughly the same. Perhaps the interpreter as a whole is slightly faster --without-threads? That would explain the remaining speed difference of 4%. Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
On May 10, 2012, at 10:57 AM, Antoine Pitrou wrote: >sys.implementation.metadata looks like a completely over-engineered >concept. Please, let's just make sys.implementation a dict and stop >bothering about ordering and iterability. I guess the question is whether immutability is useful to preserve in sys.implementation. I'm on the fence, but maybe "we're all consenting adults" and "simplest thing that will work" should rule the day. Using a straight up dict and underscores for non-PEP-defined values is certainly simple, and easy to implement and describe. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Point of building without threads?
Stefan Krah wrote: > > > Nice. This reduces the speed difference to about 4%! > > > > Note that you don't need the actual thread id, the Python thread state > > is sufficient: PyThreadState_GET should be a simply variable lookup in > > release builds. > > I've tried both ways now and the speed gain is roughly the same. > > Perhaps the interpreter as a whole is slightly faster --without-threads? > That would explain the remaining speed difference of 4%. Actually this seems to be the case: In the benchmark floats are also about 3% faster without threads. Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Point of building without threads?
On Thu, 10 May 2012 20:23:08 +0200 Stefan Krah wrote: > Antoine Pitrou wrote: > > On Wed, 9 May 2012 11:26:29 +0200 > > Stefan Krah wrote: > > > Antoine Pitrou wrote: > > > > > _decimal is about 12% faster without threads, because the expensive > > > > > thread local context can be disabled. > > > > > > > > If you cached the last thread id along with the corresponding context, > > > > perhaps it could speed things up in most scenarios? > > > > > > Nice. This reduces the speed difference to about 4%! > > > > Note that you don't need the actual thread id, the Python thread state > > is sufficient: PyThreadState_GET should be a simply variable lookup in > > release builds. > > I've tried both ways now and the speed gain is roughly the same. > > Perhaps the interpreter as a whole is slightly faster --without-threads? > That would explain the remaining speed difference of 4%. It may be. Can you try other benchmarks? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
Nick Coghlan wrote: On Thu, May 10, 2012 at 6:57 PM, Antoine Pitrou wrote: On Thu, 10 May 2012 11:33:14 +1000 Nick Coghlan wrote: The original concern (that sys.implementation may differ in length across implementations) has been eliminated by moving all implementation specific values into sys.implementation.metadata. Uh. It's scary the kind of things people sometimes come up with :-) sys.implementation.metadata looks like a completely over-engineered concept. Please, let's just make sys.implementation a dict and stop bothering about ordering and iterability. Aye. Add a rule that all implementation specific (i.e. not defined in the PEP) keys must be prefixed with an underscore and I'm sold. So now we're adding a new convention to single underscore names? Single underscore names are implementation-specific details that you shouldn't use or rely on, except in sys.implementation, where they are an optional part of the public interface. There are public keys which all Pythons are expected to support. There are public keys which only some Pythons are expected to support. We may call them "implementation-specific", but that refers to the PYTHON implementation, not the implementation of sys.implementation. As far as sys.implementation is concerned, these keys are public but optional, not private. Hence labelling them with a single underscore overrides the convention that _single underscore names are private, for one that they are public but optional. I'm not so sure that this is a good idea. To bike-shed a moment, if we're going to stick to a dict, and you really think that it is important to have a naming convention to distinguish between optional keys and those common to all Pythons, perhaps a better convention would be to prefix the optional keys with a dot, or a dash. This introduces a new convention without clashing with an existing one. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
Scott Dial wrote: On 5/10/2012 1:40 AM, Nick Coghlan wrote: Unordered types can be a PITA for testing, for display and for generic serialisation, so I definitely want to see a PEP before we add a new one that basically has its sole reason for existence being "you can iterate over and index the field values in a namedtuple". I could use those same arguments (testing, display, and generic serialization) as reasons /against/ using an ordered type (when it's not the intent of the author that it be ordered). That is: - Testing: This is an attractive nuisance because adding fields later can break the tests if the author of the type had no intent on the ordering being guaranteed (or the number of fields). As opposed to unordered types when you add a new field? I don't think so. When you add new fields, you can break tests *regardless* of whether the type is ordered or unordered. If you change the public interface to a type, you have to change any tests that rely on it. But unordered types have a tendency to break tests even when you don't add new fields (at least doctests), simply because their display can arbitrarily change. Given the choice between having to re-write tests once in a blue moon when there is a backwards-incompatible change to a type, and having tests randomly break every time I run them because the display is unpredictable, I know which one I prefer. +1 to Nick's request for a PEP. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Allow use of sphinx-autodoc in the standard library documentation?
Thanks, that's pretty much what I thought (although I hadn't considered the sys.path and version dependency) . I'll proceed with the original plan. Cheers, Nick. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] sys.implementation
No, they're private keys for the benefit of the implementation authors. Still, it's already the case that underscore prefixed names are sometimes used just for namespace separation (e.g. collections.namedtuple) -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
On Fri, May 11, 2012 at 3:31 AM, Barry Warsaw 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 | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding types.build_class for 3.3
Nick Coghlan wrote:
On Fri, May 11, 2012 at 3:31 AM, Barry Warsaw 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
