Showing content from http://mail.python.org/pipermail/python-dev/attachments/20140607/e65af8df/attachment.html below:
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#330033">
<div class="moz-cite-prefix">
<div class="moz-cite-prefix">On 6/7/2014 7:50 AM, Antoine Pitrou
wrote:<br>
</div>
<blockquote cite="mid:lmv8r8$dae$1@ger.gmane.org" type="cite">Le
07/06/2014 09:25, R. David Murray a écrit : <br>
<blockquote type="cite">On Fri, 06 Jun 2014 19:50:57 +0100,
Chris Withers <a class="moz-txt-link-rfc2396E" href="mailto:chris@simplistix.co.uk"><chris@simplistix.co.uk></a> wrote:
<br>
<blockquote type="cite">I guess I could duck-type it based on
the _fields attribute but that
<br>
feels implicit and fragile.
<br>
<br>
What do you guys suggest?
<br>
</blockquote>
<br>
I seem to remember a previous discussion that concluded that
duck typing
<br>
based on _fields was the way to go. (It's a public API,
despite the _,
<br>
due to name-tuple's attribute namespacing issues.)
<br>
</blockquote>
<br>
There could be many third-party classes with a _fields member,
so that sounds rather fragile. <br>
There doesn't seem to be any technical reason barring the
addition of a common base class for namedtuples. <br>
<br>
Regards <br>
<br>
Antoine.<br>
</blockquote>
<br>
A common base class sounds like a good idea, to me, at a minimum,
to help identify all the namedtuple derivatives.<br>
<br>
<br>
On 6/7/2014 7:46 AM, Nick Coghlan wrote:<br>
</div>
<blockquote
cite="mid:CADiSq7fUZvDGg34Tjqp3pkHhg-zmLyCGSj0QEox6W9S1dOAryQ@mail.gmail.com"
type="cite">
<pre wrap="">On 7 June 2014 04:50, Chris Withers <a class="moz-txt-link-rfc2396E" href="mailto:chris@simplistix.co.uk"><chris@simplistix.co.uk></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">
In principle, you could get the equivalent of collections.namedtuple
through dynamically constructed classes. In practice, that's actually
easier said than done, so the fact the current implementation works
fine for almost all purposes acts as a powerful disincentive to
rewriting it. 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.
</pre>
</blockquote>
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 implementation.
namedtuple predates of the improvements in metaclasses, also, which
may be a justification for the present implementation.<br>
<br>
I bumped into namedtuple when I first started coding in Python, I
was looking for _some way_, _any way_ to achieve an unmutable class
with named members, and came across Raymond's recipe, which others
have linked to... and learned, at the time, that he was putting it
into Python stdlib. I found it far from "*really* easy to
understand", although at that point in my Python knowledge, I highly
doubt a metaclass implementation would have been easier to
understand... but learning metaclasses earlier than I did might have
been good for my general understanding of Python, and more useful in
the toolbox than an implementation like namedtuple. I did, however,
find and suggest a fix for a bug in the namedtuple implementation
that Raymond was rather surprised that he had missed, although I
would have to pick through the email archives to remember now what
it was, or any other details about it... but it was in time to get
fixed before the first release of Python that included namedtuple,
happily.<br>
<br>
I wouldn't be opposed to someone rewriting namedtuple using
metaclasses, to compare the implementations from an
understandability and from an efficiency standpoint... but I don't
think my metaclass skills are presently sufficient to make the
attempt myself.<br>
<br>
I also seem to recall that somewhere in the (lengthy) Enum
discussions, that Enum uses a technique similar to namedtuple, again
for an efficiency reason, even though it also uses metaclasses in
its implementation.<br>
<br>
I wonder if, if the reasons were well understood by someone that
understand Python internals far better than I do, if they point out
some capability that is missing from metaclasses that lead to these
decisions to use string parsing and manipulation as a basis for
implementing classes with metaclass-like behaviors, yet not use the
metaclass feature set to achieve those behaviors.<br>
<br>
Glenn<br>
</body>
</html>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4