[Raymond Hettinger]
> The constructor signature ... Point(*fetchall(s)),
> and it allows for direct construction with Point(2,3) without
> the slower and weirder form: Point((2,3)).
[Jim Jewett]
>> If you were starting from scratch, I would agree
>> whole-heartedly; this is one of my most frequent
>> mistakes.The question is whether it makes sense to
>> "fix" NamedTuple without also fixing regular tuple, list,
Yes. Tuples and lists both have syntactic support for direct construction and
NamedTuples aspire to that functionality:
vec = (dx*3.0, dy*dx/dz, dz) # Regular tuple
vec = Vector(dx*3.0, dy*dx/dz, dz) # Named tuple
I've worked with the current version of the recipe for a long time and after a
while the wisdom of the signature becomes self-evident. We REALLY don't want:
vec = Vector((dx*3.0, dy*dx/dz, dz)) # yuck
For conversion from other iterables, it is REALLY easy to write:
vec = Vector(*partial_derivatives)
Remember, list() and tuple() are typically used as casts, not as direct
constructors. How often do you write:
dlist = list((dx*3.0, dy*dx/dz, dz))
That is usually written:
dlist = [dx*3.0, dy*dx/dz, dz]
I think the Vec((dx, dy, dz)) sysntax falls into the category of foolish
consistency.
Raymond
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
