>> I wonder how a hybrid approach would work? Use a dynamically-created
>> class, but then construct the __new__ method using exec and inject it
>> into the new class. As far as I can see, it's only __new__ that benefits
>> from the exec approach.
>>
>> Anyone tried this yet? Is it worth an expe
On Jun 9, 2014, at 4:40 AM, Antoine Pitrou wrote:
> Instead of an ABC, why not a simple is_namedtuple() function?
That would work.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Le 09/06/2014 00:05, Raymond Hettinger a écrit :
Another issue is that a straight abc wouldn't be sufficient. What we
would really want is to check for is:
1) the presence of a _fields tuple (an abc can do this)
2) to check that all of the attribute names specified in _fields are
defined (ABCMe
On Jun 8, 2014, at 6:42 PM, Nick Coghlan wrote:
> >> I seem to remember a previous discussion that concluded that duck typing
> >> based on _fields was the way to go. (It's a public API, despite the _,
> >> due to name-tuple's attribute namespacing issues.)
> >
> >
> > Yes. That is the recomme
On 9 Jun 2014 10:04, "Raymond Hettinger"
wrote:
>
>
> On Jun 7, 2014, at 6:25 AM, R. David Murray wrote:
>
>>> I guess I could duck-type it based on the _fields attribute but that
>>> feels implicit and fragile.
>>>
>>> What do you guys suggest?
>>
>>
>> I seem to remember a previous discussion t
On 6/8/2014 7:31 PM, Steven D'Aprano wrote:
> On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote:
>> On 6/7/2014 10:46 AM, Nick Coghlan wrote:
>>> On 7 June 2014 04:50, Chris Withers wrote:
Curious as to what lead to that implementation approach? What does it buy
that couldn't
On Jun 7, 2014, at 6:25 AM, R. David Murray wrote:
>> I guess I could duck-type it based on the _fields attribute but that
>> feels implicit and fragile.
>>
>> What do you guys suggest?
>
> I seem to remember a previous discussion that concluded that duck typing
> based on _fields was the way
On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote:
> On 6/7/2014 10:46 AM, Nick Coghlan wrote:
> > On 7 June 2014 04:50, Chris Withers wrote:
> >> Curious as to what lead to that implementation approach? What does it buy
> >> that couldn't have been obtained by a mixin providing the fu
Le 08/06/2014 18:44, R. David Murray a écrit :
For what it is worth, I found the discussion I was remembering:
http://bugs.python.org/issue7796
And as someone pointed out down thread, the actual check is "inherits
from tuple and has a _fields attribute".
That gets you a duck type, which
On Sat, 07 Jun 2014 10:50:16 -0400, Antoine Pitrou wrote:
> Le 07/06/2014 09:25, R. David Murray a écrit :
> > On Fri, 06 Jun 2014 19:50:57 +0100, Chris Withers
> > wrote:
> >> I've been trying to add support for explicit comparison of namedtuples
> >> into testfixtures and hit a problem which
On Sun, Jun 08, 2014 at 05:27:41PM -0400, Eric V. Smith wrote:
> How would you write _Namedtuple.__new__?
Knew something must be missing :) Obviously it's possible, but not
nearly as efficiently as reusing the argument parsing machinery as in
the original implementation.
I guess especially the
On 6/8/2014 3:37 PM, dw+python-...@hmmz.org wrote:
> On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote:
>
>>> The current implementation is also *really* easy to understand,
>>> while writing out the dynamic type creation explicitly would likely
>>> require much deeper knowledge of the
On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote:
> > The current implementation is also *really* easy to understand,
> > while writing out the dynamic type creation explicitly would likely
> > require much deeper knowledge of the type machinery to follow.
> As proof that it's harder
On Sun, Jun 08, 2014 at 07:37:46PM +, dw+python-...@hmmz.org wrote:
> cls = tuple(name, (_NamedTuple,), {
Ugh, this should of course have been type().
David
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
On 6/7/2014 10:46 AM, Nick Coghlan wrote:
> On 7 June 2014 04:50, Chris Withers wrote:
>> Curious as to what lead to that implementation approach? What does it buy
>> that couldn't have been obtained by a mixin providing the functionality?
>
> In principle, you could get the equivalent of collect
On 8 Jun 2014 05:44, "Glenn Linderman" wrote:
>
> I wonder if the dynamically constructed classes approach could lead to
the same space and time efficiencies... seems like I recall there being a
discussion of efficiency, I think primarily space efficiency, as a
justification for the present implem
Hello,
On Sat, 07 Jun 2014 12:42:32 -0700
Glenn Linderman wrote:
> On 6/7/2014 7:50 AM, Antoine Pitrou wrote:
> > Le 07/06/2014 09:25, R. David Murray a écrit :
> >> On Fri, 06 Jun 2014 19:50:57 +0100, Chris Withers
> >> wrote:
> >>> I guess I could duck-type it based on the _fields attribute
On 6/7/2014 7:50 AM, Antoine Pitrou wrote:
Le 07/06/2014 09:25, R. David Murray a écrit :
On Fri, 06 Jun 2014 19:50:57 +0100, Chris Withers
wrote:
I guess I could duck-type it based on the _fields attribute but that
feels implicit and fragile.
What do you guys suggest?
I seem to remember a
Le 07/06/2014 09:25, R. David Murray a écrit :
On Fri, 06 Jun 2014 19:50:57 +0100, Chris Withers
wrote:
I've been trying to add support for explicit comparison of namedtuples
into testfixtures and hit a problem which lead me to read the source and
be sad.
Rather than the mixin and class assem
On 7 June 2014 04:50, Chris Withers wrote:
> Curious as to what lead to that implementation approach? What does it buy
> that couldn't have been obtained by a mixin providing the functionality?
In principle, you could get the equivalent of collections.namedtuple
through dynamically constructed cl
On Fri, Jun 06, 2014 at 07:50:57PM +0100, Chris Withers wrote:
> Hi All,
>
> I've been trying to add support for explicit comparison of namedtuples
> into testfixtures and hit a problem which lead me to read the source and
> be sad.
>
> Rather than the mixin and class assembly in the function I
On Fri, 06 Jun 2014 19:50:57 +0100, Chris Withers
wrote:
> I've been trying to add support for explicit comparison of namedtuples
> into testfixtures and hit a problem which lead me to read the source and
> be sad.
>
> Rather than the mixin and class assembly in the function I expected to
> f
Hi All,
I've been trying to add support for explicit comparison of namedtuples
into testfixtures and hit a problem which lead me to read the source and
be sad.
Rather than the mixin and class assembly in the function I expected to
find, I'm greeted by an exec of a string.
Curious as to wha
23 matches
Mail list logo
