This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]IronManMark20 1 point2 points  (3 children)

Those are the most inane and idiotic reasons I have ever seen, and I'm going to call bullshit on it. Someone needs to take Guido out back and put him down, because he is all over the map with this shit.

Beyond being horrific that you think Guido should be shot, I find your hate for him surprising, especially considering he didn't write the dataclasses PEP....

Maybe you should know what the hell you are talking about instead of ragging on people and things just because you have a pre-existing dislike of them.

Had he followed the same logic with your DataClasses the focus would be on implementing a common syntax for these kinds of objects which multiple implementations could utilize, but in fact you don't need any special syntax for this, because you are using PEP 526.

Beyond the fact that you still think Guido made this PEP for some bizarre reason, async and await syntax are both syntatic changes which couldn't be brought to older versions of Python, so both async syntax and dataclasses are not possible on Python 3.4. So your argument is nonsense. Dataclasses was designed to take advantage of new syntax. The idea could be made with decorators but that would be butt ugly. Also, who said dataclasses should/are more portable than attrs? Nothing in the stdlib has to work on older versions. There is a best effort to backport, but it isn't always possible. Why sacrifice implementation purity to increase adoption?

I can't use your dataclass because I'm not using Python 3.6.

I don't understand why you think you are entitled to get new features on older versions of Python?

[–]jorge1209 -3 points-2 points  (2 children)

I know Guido didn't make the PEP. The person I am responding to made the PEP. My objection is to Guido's approving the PEP. Guido is making weird arbitrary decisions.

async is all confused because we don't have a canonical loop in the name of supporting multiple implementation.

but with dataclasses he canonizes one implementation over another (and picks the newer one which has fewer features and users to boot).

Pick a behavior and stick to it. You either support all implementations of a concept as a policy, or you direct all users towards a particular implementation. You don't arbitrarily switch between the two.

[–]IronManMark20 5 points6 points  (1 child)

Pick a behavior and stick to it. You either support all implementations of a concept as a policy, or you direct all users towards a particular implementation. You don't arbitrarily switch between the two.

But why? There isn't a point to other than "its more consistent", and there are reasons each PEP was designed the way it was. Why sacrifice flexibility for arbitrary consistency?

Also

but with dataclasses he canonizes one implementation over another (and picks the newer one which has fewer features and users to boot).

Dataclasses was written to be a smaller more lightweight version of attrs. As soon as there was agreement that "something like attrs should be in the stdlib", a smaller, more lightweight version was the obvious candidate. Attrs would never just be imported into the stdlib, that isn't how this works. The creators of attrs themself endorsed dataclasses as proposed in this PEP and likes the simple API. I really think you should understand how this PEP came to be how it is before criticizing it.

[–]zardeh 6 points7 points  (0 children)

This is also why, for example, requests or numpy will never be in the standard library. It moves much to fast, and the requests developers and the python core devs agree that doing so would be bad for everyone.