Dataclasses have a lot of issues, including requiring type annotations, too many features, poor performance, etc. People want to have basic data types that are easy to define and simple to use without all the overhead of OOP. Also, immutable types like this could enable better sharing between sub-interpreters for performance.
I couldn’t really see the difference with a NamedTuple subclasses, which behave pretty much like structs, the only caveat being reserved attribute names like ‘index’.
Namedtuple allows positional access, which is an error-prone interface that should be avoided. Namedtuples are really only there to help you migrate existing tuple code over to objects with attributes.
With the “I haven’t done Python in a while” caveat, I wonder — why not make a new namedtuple-like that doesn’t allow indexing? The Author’s reference implementation could easily be the template here, no?
Maybe the underlying question is “why can’t it just be a new collection class? why is built-in language support and a new struct keyword needed?” I think it’s this part:
def __new__(cls, x: int, y: int) -> Self:
"""Create a new, immutable instance."""
# Pretend this makes everything immutable in the end.
self = mutable(cls.__slots__)
self.x = x
self.y = y
return immutable(self)
There’s no immutable in userspace today as far as I understand it. Some values like frozenset and tuple are actually immutable, and there are proposals for others, but not for objects. You can simulate immutability like dataclasses already do but it’s not truly frozen. SimpleNamespace is fully mutable. So that’s part of the gap to fill.
If the goal is performance, aren’t you in the wrong language? At some point either the dynamic features of the language are worth having, or they need to be shed (yes, pun). But what I see happening (from a far) is that the language keeps growing and growing in language surface area instead of fixing/creating better baseline abstractions. We’re just minutes away from Python being the next “kitchen sink” language… it seems. Far from the language I loved using in the 00s and early 10s.
But why is it good to discuss it? What does this offer that dataclasses don’t? Honest question here, because I’m not seeing it, but I could be missing something.
One problem with @dataclass being an annotation is that it will either create a new class or modify an existing class based on slots=True, and creating a new class is an odd behavior as well. Syntax could unify this to a degree and simplify it too.
Additionally, people won’t choose @dataclass as often. It’s one of those things that is less likely to be reached for because people prefer native features.
That’s about it though. Personally, I don’t really think a native version is a big win tbh
One of my biggest issues with dataclasses, specially working with people without a lot of python experience, is that it’s based on deep, dark, magic. The second someone asks “why do I have to put this @symbol over my class”, bam, you either have to say “Trust me, you just have to”, or you will spend the next 7 hours explaining how decorators work and what even are metaclasses.
Decorators are just functions that take objects, modify or wrap them, and return a new object. Metaclasses need not apply for a basic understanding of decorators. Far cry from “black magic,” I’d say.
edit: and upon inspection of the dataclasses source, I don’t think it actually relies on metaclasses at all.
Point taken on metaclasses, although it’s worth mentioning that lots of other libraries that provide similar functionality to dataclasses use metaclasses, and so does other stuff on the stdlib, like enums.
That said, decorators are only simple if you know them. Even the concept of functions as first class objects can be startling to newcomers. Would be nice if one could introduce simple data objects without having to go into that.
I’m not really convinced. Going through the authors points:
Focus: Humans can only focus on one thing at a time.
Humans only do well focusing on one task at a time. For me as a web developer, that can mean I’m toggling between my editor, my browser, and my terminal. These are spread across two windows, but I’m still working on one task at a time.
If my email or social media feeds are available at a glance, then I’ll check them constantly.
This is a bad idea, but just because you have two monitors up, doesn’t mean you need to put Twitter on one of them.
As Barry Schwartz explores in “The Paradox of Choice”, decision fatigue is a real problem. Sometimes, more is less. […] With a single screen, I eliminate decisions. I don’t waste time deciding where to drag windows or fiddling with where to place a given window.
For me personally I don’t spend any brain energy on where my windows go. IDE on the left, browser on the right. Even when I’m moving things around to see two browsers side-by-side it is just a non-issue for me.
So I treat virtual desktops like physical screens that reliably present the same content.
That’s great, but you can also just have two monitors to do this.
Same Workflow When Remote
This is the one point that I really agreed with. However for me I find I’m much less productive on a single laptop 13” non-retina screen than I am across two 27” 4k monitors. I wouldn’t want to downgrade my desktop experience so I don’t suffer on a laptop.
When I had multiple monitors, I had to rearrange my windows every time I undocked my machine.
This is annoying, and definitely something Apple should fix.
So why do so many workers demand multiple monitors? I believe it’s a case of the illogical allure of extremes.
I think this is because many workers do tasks that benefit from having multiple monitors. Accountants with Excel are a great example, because the benefit of multiple screens is so obvious.
It’s great that the author is happy with a single monitor, but this seems more like a personal preference than a demonstrable improvement.
It’s great that the author is happy with a single monitor, but this seems more like a personal preference than a demonstrable improvement.
Yup. As someone who doesn’t care for multiple monitors, I found the author’s argument to be pretty weak. Arguing for the number of monitors is as fruitless as arguing Emacs vs. vi(m). If it works for you, great. Otherwise, stop preaching.
I’ve used a 21:9 monitor – 29” flat and later a 34” curved – and found that I’m far more productive with two monitors than one. I use Hammerspoon profusely with a 4x2 grid configuration while full-screening just about every app in which I need to focus: Outlook, OneNote, Slack, etc. For the most part, the “center-stage” apps stay on my laptop screen while the browser, code, and other ephemeral things traverse the big screen. It’s lovely to be able to move windows around easily and have 8 readable windows open on my Dell 34” curved ultrawide.
This is kind of a pointless article. The author doesn’t actually postulate anything of substance.
I can’t see IOS replacing MacOS. There is a HUGE installed base of Automator tasks in all kinds of environments and I can’t see that translating to IOS at all.
Isn’t Apple getting rid of Automator? I recall a source somewhere that said they removed all of the Automator staff, I think it may have been in the Hypercard discussion. Ive been thru the System 6 to 7 transition, and the 9 to X transition. Its always messy. But I am getting the feeling they want to converge macOS and iOS at some point. Just my opinion.
Wow thank you this is profoundly sad. The user sutomation suite is one of the things that keeps me a loyal OSX user. If that goes away I will be incredibly disappointed.
There is an incredible amount of power inherent in being able to control and customize the state of running apps programmatically from userland. It’s a very old idea and I don’t understand why people seem so keen on tossing it into the scrap heap.
Things like Quark Xpress, Adobe InDesign, and the like. Basically, you have a complex workflow in one of these apps that you need to do over and over, Applescript / Automator are a great way to make that happen.
I don’t get it. Dataclasses are already compact. This seems like new syntax for the sake of adding new syntax.
Dataclasses have a lot of issues, including requiring type annotations, too many features, poor performance, etc. People want to have basic data types that are easy to define and simple to use without all the overhead of OOP. Also, immutable types like this could enable better sharing between sub-interpreters for performance.
I couldn’t really see the difference with a NamedTuple subclasses, which behave pretty much like structs, the only caveat being reserved attribute names like ‘index’.
Namedtuple allows positional access, which is an error-prone interface that should be avoided. Namedtuples are really only there to help you migrate existing tuple code over to objects with attributes.
With the “I haven’t done Python in a while” caveat, I wonder — why not make a new namedtuple-like that doesn’t allow indexing? The Author’s reference implementation could easily be the template here, no?
Maybe the underlying question is “why can’t it just be a new collection class? why is built-in language support and a new
structkeyword needed?” I think it’s this part:There’s no
immutablein userspace today as far as I understand it. Some values likefrozensetandtupleare actually immutable, and there are proposals for others, but not for objects. You can simulate immutability like dataclasses already do but it’s not truly frozen. SimpleNamespace is fully mutable. So that’s part of the gap to fill.So the right thing to do is to make it possible to have immutable class fields, not create a literally new structure/syntax in the language… maybe?
All of the object and class machinery is very expensive, though. So the goal is to avoid that because of performance. Makes sense to me.
If the goal is performance, aren’t you in the wrong language? At some point either the dynamic features of the language are worth having, or they need to be shed (yes, pun). But what I see happening (from a far) is that the language keeps growing and growing in language surface area instead of fixing/creating better baseline abstractions. We’re just minutes away from Python being the next “kitchen sink” language… it seems. Far from the language I loved using in the 00s and early 10s.
Oh well.
I agree it no longer “fits in your head”.
It seems like Mojo is sort of working in that same direction.
This could be a package for structs, does not seem to be needed in the language definition itself. But its good to discuss it.
But why is it good to discuss it? What does this offer that dataclasses don’t? Honest question here, because I’m not seeing it, but I could be missing something.
One problem with
@dataclassbeing an annotation is that it will either create a new class or modify an existing class based onslots=True, and creating a new class is an odd behavior as well. Syntax could unify this to a degree and simplify it too.Additionally, people won’t choose
@dataclassas often. It’s one of those things that is less likely to be reached for because people prefer native features.That’s about it though. Personally, I don’t really think a native version is a big win tbh
One of my biggest issues with dataclasses, specially working with people without a lot of python experience, is that it’s based on deep, dark, magic. The second someone asks “why do I have to put this @symbol over my class”, bam, you either have to say “Trust me, you just have to”, or you will spend the next 7 hours explaining how decorators work and what even are metaclasses.
Decorators are just functions that take objects, modify or wrap them, and return a new object. Metaclasses need not apply for a basic understanding of decorators. Far cry from “black magic,” I’d say.
edit: and upon inspection of the dataclasses source, I don’t think it actually relies on metaclasses at all.
Point taken on metaclasses, although it’s worth mentioning that lots of other libraries that provide similar functionality to dataclasses use metaclasses, and so does other stuff on the stdlib, like enums.
That said, decorators are only simple if you know them. Even the concept of functions as first class objects can be startling to newcomers. Would be nice if one could introduce simple data objects without having to go into that.
I had no idea, always wondered why they used
wheelfor the sudoers group.I always envisioned it like a spoke on a wheel which gets rotated up to gain privileges.
I always thought it came from driving / ‘you take the wheel’.
I’m not really convinced. Going through the authors points:
Humans only do well focusing on one task at a time. For me as a web developer, that can mean I’m toggling between my editor, my browser, and my terminal. These are spread across two windows, but I’m still working on one task at a time.
This is a bad idea, but just because you have two monitors up, doesn’t mean you need to put Twitter on one of them.
For me personally I don’t spend any brain energy on where my windows go. IDE on the left, browser on the right. Even when I’m moving things around to see two browsers side-by-side it is just a non-issue for me.
That’s great, but you can also just have two monitors to do this.
This is the one point that I really agreed with. However for me I find I’m much less productive on a single laptop 13” non-retina screen than I am across two 27” 4k monitors. I wouldn’t want to downgrade my desktop experience so I don’t suffer on a laptop.
This is annoying, and definitely something Apple should fix.
I think this is because many workers do tasks that benefit from having multiple monitors. Accountants with Excel are a great example, because the benefit of multiple screens is so obvious.
It’s great that the author is happy with a single monitor, but this seems more like a personal preference than a demonstrable improvement.
Yup. As someone who doesn’t care for multiple monitors, I found the author’s argument to be pretty weak. Arguing for the number of monitors is as fruitless as arguing Emacs vs. vi(m). If it works for you, great. Otherwise, stop preaching.
This right here. And when I am doing server maintenance - terminal on the left, massive spreadsheet checklist on the right.
I agree with all of this.
I’ve used a 21:9 monitor – 29” flat and later a 34” curved – and found that I’m far more productive with two monitors than one. I use Hammerspoon profusely with a 4x2 grid configuration while full-screening just about every app in which I need to focus: Outlook, OneNote, Slack, etc. For the most part, the “center-stage” apps stay on my laptop screen while the browser, code, and other ephemeral things traverse the big screen. It’s lovely to be able to move windows around easily and have 8 readable windows open on my Dell 34” curved ultrawide.
This is kind of a pointless article. The author doesn’t actually postulate anything of substance.
I can’t see IOS replacing MacOS. There is a HUGE installed base of Automator tasks in all kinds of environments and I can’t see that translating to IOS at all.
Isn’t Apple getting rid of Automator? I recall a source somewhere that said they removed all of the Automator staff, I think it may have been in the Hypercard discussion. Ive been thru the System 6 to 7 transition, and the 9 to X transition. Its always messy. But I am getting the feeling they want to converge macOS and iOS at some point. Just my opinion.
Oh I very sincerely doubt that. Some of Apple’s biggest clients are huge desktop publishing houses that have crazy complicated Automator workflows.
I did some googling and couldn’t find any reference to this - don’t mean to be a pain but - got a cite? Curious to see your source.
This is what I found, but its not the article I remember reading (which was recent),
https://9to5mac.com/2016/11/17/mac-user-automation-sal-soghoian/
Wow thank you this is profoundly sad. The user sutomation suite is one of the things that keeps me a loyal OSX user. If that goes away I will be incredibly disappointed.
There is an incredible amount of power inherent in being able to control and customize the state of running apps programmatically from userland. It’s a very old idea and I don’t understand why people seem so keen on tossing it into the scrap heap.
The AppleScript/OSE team has been gutted and the lead left the position.
Interested in your comment about publishing houses with automator workflows. What programs do they need Automator workflows for?
Things like Quark Xpress, Adobe InDesign, and the like. Basically, you have a complex workflow in one of these apps that you need to do over and over, Applescript / Automator are a great way to make that happen.
OK, and, now a month later, what’s utterly HILARIOUS IMO is that IOS 11 makes IOS more MacOS X like! It’s getting the Dock, Spaces, etc etc.
Maybe they’ll port Applescript to IOS? :) (j/k)