On Thu, May 10, 2012 at 3:34 PM, "Martin v. Löwis" wrote:
>> We've been over this before: collections.namedtuple *is* the standard
>> library's answer for structured records.
>
>
> And I think it's a really ugly answer, and one that deserves a parallel
> that is not a tuple. If this is contentious
We've been over this before: collections.namedtuple *is* the standard
library's answer for structured records.
And I think it's a really ugly answer, and one that deserves a parallel
that is not a tuple. If this is contentious, I'll write a PEP.
Regards,
Martin
_
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
On Wed, May 9, 2012 at 7:33 PM, Nick Coghlan wrote:
> Please, no. No new
> just-like-a-namedtuple-except-you-can't-iterate-over-it type, and
> definitely not one exposed in the collections module.
>
> We've been over this before: collections.namedtuple *is* the standard
> library's answer for stru
On May 09, 2012, at 05:47 PM, Larry Hastings wrote:
>I like Alex Martelli's approach, which I recall was exactly this:
>
>class namespace:
> def __init__(**kwargs):
> self.__dict__ = kwargs
>
>
>That means all the initializers you pass in to the constructor get turned
>into
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().
Not tr
On Thu, May 10, 2012 at 2:53 AM, Barry Warsaw wrote:
> On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
>
>>Sure, but couldn't we define this "empty" class in C code so that you can
>>use the C API with it as well and just provide a C function to get a new
>>instance?
>
> +1
>
> ISTM to be a comp
On 05/09/2012 09:53 AM, Barry Warsaw wrote:
On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
Sure, but couldn't we define this "empty" class in C code so that you can
use the C API with it as well and just provide a C function to get a new
instance?
+1
ISTM to be a companion to collections.n
On Wed, May 9, 2012 at 10:39 AM, Barry Warsaw wrote:
> On May 08, 2012, at 09:03 PM, Eric Snow wrote:
>>Definitely tangled. So, sys.implementation.version and
>>sys.implementation.lang_version? Also, my inclination is to not have
>>a sys.version equivalent in sys.implementation for now, in the
>
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
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
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 :)
__
On Wed, May 9, 2012 at 12:21 PM, Barry Warsaw 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 b
On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
>Sure, but couldn't we define this "empty" class in C code so that you can
>use the C API with it as well and just provide a C function to get a new
>instance?
+1
ISTM to be a companion to collections.namedtuple. IWBNI this new type was
also exp
On May 09, 2012, at 08:51 AM, Eric Snow wrote:
>The type for sys.implementation has slowly shifted from the original
>proposal. At this point it's settled into where I think it will stay,
>a custom type. I've covered the choice of type in the rationale
>section. However, there may be merit in n
Sure, but couldn't we define this "empty" class in C code so that you can
use the C API with it as well and just provide a C function to get a new
instance?
That would be easy. All you need is a dictoffset.
Regards,
Martin
___
Python-Dev mailing lis
On May 08, 2012, at 09:03 PM, Eric Snow wrote:
>> This is defined as the version of the implementation, while
>> sys.version_info is the version of the language. The semantics of
>> sys.version_info have been sufficiently squishy in the past, as the XXX
>> implies. This PEP shouldn't try
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 na
On Wed, May 9, 2012 at 10:50 AM, Antoine Pitrou wrote:
> On Wed, 9 May 2012 10:44:59 -0400
> Brett Cannon wrote:
> >
> > > I wish there was a builtin class
> > >
> > > class record:
> > >pass
> > >
> > > which can be used to create objects which have only attributes
> > > and no
I recently added an issue
http://bugs.python.org/issue14712
to track PEP 405 integration. The code is in my sandbox repo, and I've created a
patch using the "Create Patch" button on the tracker. The diff has been created,
but I don't seem to see a "review" link to Rietveld. The issue is on Rietve
On Wed, May 9, 2012 at 8:50 AM, Antoine Pitrou wrote:
> On Wed, 9 May 2012 10:44:59 -0400
> Brett Cannon wrote:
>>
>> > I wish there was a builtin class
>> >
>> > class record:
>> > pass
>> >
>> > which can be used to create objects which have only attributes
>> > and no methods.
>
On Wed, May 9, 2012 at 8:44 AM, Brett Cannon wrote:
> On Wed, May 9, 2012 at 5:57 AM, "Martin v. Löwis"
> wrote:
>> [Update: it seems this is already reflected in the PEP. I wonder
>> where the requirement for "a new type" comes from. I think making
>> it a module should be conforming, even
On Wed, 9 May 2012 10:44:59 -0400
Brett Cannon wrote:
>
> > I wish there was a builtin class
> >
> > class record:
> >pass
> >
> > which can be used to create objects which have only attributes
> > and no methods.
>
>
> I have heard this request now a bazillion times over the ye
On Wed, May 9, 2012 at 3:57 AM, "Martin v. Löwis" wrote:
> Interesting proposal. I have a number of comments:
Thanks for taking a look, Martin.
> - namespace vs. dictionary. Barry was using it in the form
> sys.implementation.version. I think this is how it should work,
> yet the PEP says that
On Wed, May 9, 2012 at 5:57 AM, "Martin v. Löwis" wrote:
> On 27.04.2012 09:34, Eric Snow wrote:
>
>> On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw wrote:
>>
>>> It's somewhat of a corner case, but I think a PEP couldn't hurt. The
>>> rationale section would be useful, at least.
>>>
>>
>> http
On Wed, May 9, 2012 at 3:05 AM, Steven D'Aprano 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
FYI, this was at the 2011 language summit
-eric
On Wednesday 09 May 2012 08:02:09 Xavier Morel wrote:
| Erm… you have them? What do you think `<` and `>` are?
I was under the impression that those (let's call them) HTML representations
of < and > don't get interpreted correctly by Javascript engines. I'll have to
check that though..
|
| As
On Wednesday 09 May 2012 08:02:09 Xavier Morel wrote:
| Erm… you have them? What do you think `<` and `>` are?
I was under the impression that those (let's call them) HTML representations
of < and > don't get interpreted correctly by Javascript engines. I'll have to
check that though..
|
| As
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 s
On 27.04.2012 09:34, Eric Snow wrote:
On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw wrote:
It's somewhat of a corner case, but I think a PEP couldn't hurt. The
rationale section would be useful, at least.
http://mail.python.org/pipermail/python-ideas/2012-April/014954.html
Interesting p
Is there a better way?
Dear Alex,
As Terry indicates: python-dev is a list for the development *of*
Python, not the development *with* Python. Use the general python-list
or the xml-sig list for this kind of question.
Regards,
Martin
___
Python-De
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 di
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
Nick Coghlan wrote:
On Wed, May 9, 2012 at 5:57 PM, 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.
We'll make sure it *beha
On Wed, May 9, 2012 at 5:57 PM, 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.
We'll make sure it *behaves* like a static
Nick Coghlan wrote:
On Wed, May 9, 2012 at 4:37 PM, Daniel Urban wrote:
On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan 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/issu
On Wed, May 9, 2012 at 4:37 PM, Daniel Urban wrote:
> On Wed, May 9, 2012 at 3:10 AM, Nick Coghlan 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)
> obt
37 matches
Mail list logo
