[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
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