Hello,
I would like some help understanding the build system. I am currently
working on an issue (http://bugs.python.org/issue21627) and plan to
create some common functionality in Python/setcloexec.c and
Include/setcloexec.h that is conditionally compiled in on POSIX
systems and not on Windows sy
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
13 matches
Mail list logo
