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_cla
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 su
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 so
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 t
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
> m
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.implem
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 ty
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 s
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.met
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.
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 val
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 i
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
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 correspo
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 preser
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 g
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.
>
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 sy
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 f
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
Python-Dev
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 :)
__
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, perhap
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
23 matches
Mail list logo
