3 ms·

Obviously, practicality should beat purity and very clever and reasobable syntax (x=1, y=2) which could be used/generalized for a procedure arguments and e

by lngnmn 9y ago

Obviously, practicality should beat purity and very clever and reasobable syntax (x=1, y=2) which could be used/generalized for a procedure arguments and effecient implementation in C (we have C-based arrays (lists) and hash-tables, so why not generalized records/tuples?) should be accepted. The problem with a "pure democracy" is that majority cannot be smarter than the top 5% individuals, so really good ideas almost never getting thorough the bulk of a bell curve.

joejev 9y ago
Why is (x=1, y=2) more practical than nt(x=1, y=2)? Also, we have a very efficient implementation for tuples. collections.namedtuple is quite fast and the article shows cnamedtuple (which I am the author of) which is a C implementation that is even faster. None of this needs a change to the language itself.
- rplnt 9y ago
  > Why is (x=1, y=2) more practical than nt(x=1, y=2)? It was outlined in the linked article. Order of named arguments should not matter so new syntax would be better.
joshuamorton 9y ago
I think a strong argument against that syntax is that namedtuples are, essentially, an abstract class (or maybe a metaclass). An anonymous namedtuple doesn't really make sense. You want the type information. As of python 3.6, this is already possible: class Point2D(typing.NamedTuple): x: int y: int p = Point2D(x=2, y=4) If you allow anonymous namedtuples you lose one of the big values of a namedtuple, which is that if I want a Point2D, you can be sure I'm getting a Point2D, and not a Point3D. With anonymous namedtuples, there's nothing stopping you from passing a (x=2, y=3, z=4), when you wanted a (x=2, y=3). And maybe that will work fine, but maybe not (or the reverse). All this is to say, an anonymous namedtuple is an oxymoron. NamedTuples should be named. This isn't a "really good idea".
adambyrtek 9y ago
> The problem with a "pure democracy" is that majority cannot be smarter than the top 5% individuals, so really good ideas almost never getting thorough the bulk of a bell curve. Python is governed as "benevolent dictatorship" (with Guido as BDFL and maintainers as your "top 5%"), definitely not "pure democracy", so your argument doesn't really hold. When it comes to the syntax, just because something is "very clever" doesn't mean that it's necessarily a good idea. Syntax changes should be carefully considered and introduced only if the benefit clearly outweighs the cost of extra complexity. If you still believe that it's such a good idea then feel free to draft a PEP: https://www.python.org/dev/peps/ https://www.python.org/dev/peps/
GlennS 9y ago
Or, perhaps: {"x": 1, "y": 2}

by lngnmn 9y ago

joejev 9y ago

Why is (x=1, y=2) more practical than nt(x=1, y=2)? Also, we have a very efficient implementation for tuples. collections.namedtuple is quite fast and the article shows cnamedtuple (which I am the author of) which is a C implementation that is even faster. None of this needs a change to the language itself.

rplnt 9y ago
> Why is (x=1, y=2) more practical than nt(x=1, y=2)? It was outlined in the linked article. Order of named arguments should not matter so new syntax would be better.

joshuamorton 9y ago

I think a strong argument against that syntax is that namedtuples are, essentially, an abstract class (or maybe a metaclass). An anonymous namedtuple doesn't really make sense. You want the type information. As of python 3.6, this is already possible: class Point2D(typing.NamedTuple): x: int y: int p = Point2D(x=2, y=4) If you allow anonymous namedtuples you lose one of the big values of a namedtuple, which is that if I want a Point2D, you can be sure I'm getting a Point2D, and not a Point3D. With anonymous namedtuples, there's nothing stopping you from passing a (x=2, y=3, z=4), when you wanted a (x=2, y=3). And maybe that will work fine, but maybe not (or the reverse). All this is to say, an anonymous namedtuple is an oxymoron. NamedTuples should be named. This isn't a "really good idea".

adambyrtek 9y ago

> The problem with a "pure democracy" is that majority cannot be smarter than the top 5% individuals, so really good ideas almost never getting thorough the bulk of a bell curve. Python is governed as "benevolent dictatorship" (with Guido as BDFL and maintainers as your "top 5%"), definitely not "pure democracy", so your argument doesn't really hold. When it comes to the syntax, just because something is "very clever" doesn't mean that it's necessarily a good idea. Syntax changes should be carefully considered and introduced only if the benefit clearly outweighs the cost of extra complexity. If you still believe that it's such a good idea then feel free to draft a PEP: https://www.python.org/dev/peps/ https://www.python.org/dev/peps/

GlennS 9y ago

Or, perhaps: {"x": 1, "y": 2}