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
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
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 :)
__
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
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
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
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.
>
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 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
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 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
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 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 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 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 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
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, 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
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
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, 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
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
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
23 matches
Mail list logo
