It's hard to completely get away from objects in Python, but I don't think that needs to be an objective to get away from OOP patterns. My suggestions would be:
- Don't use classes for information. Use regular data structures (dict, list, tuple, set) and use functions to manipulate them. If you really want/need something like a struct, use a dataclass.
- The itertools module has a bunch of useful constructs for creating and combining iterators. Take advantage of Python's iterators and construct your own when necessary.
- List comprehensions and generator expressions are great for clear and concise data transformations
- You're going to have to deal with state somewhere in your program. That's fine, some state is necessary to do real work. Don't feel bad about creating classes for things like context managers (e.g. for a database connection) so you can use it in a with statement and it will handle the setup and teardown logic for you. That way your business logic stays concise and Pythonic since those classes can be in separate modules and imported as necessary. I've found this 'functions in the front, classes in the back' approach to writing Python useful as it lets me think about what my program does in a functional manner without denying myself the ergonomics of Python's class-based ecosystem.
> Ideology is inescapable. To some extent, everyone is under its influence. But that does not mean that all are equally ideological
The author makes this point very plainly. The 'well it's all ideology anyway' take is reductive and uses relativism to (poorly) justify people supporting ideas that are harmful to both themselves and to society.
In the same way that acknowledging that human conflict is inevitable doesn't justify violence, the existence of ideology doesn't justify structuring one's entire life around it.
> Would dedicated engineering time for a short time improve the situation and benefit the whole organization?
This applies to literally every software company ever. There's also too much vague corporate jargon to make it clear what specifically the role involves that makes it meaningfully different from DevOps.
> A different but equally important part of the team’s job is to architect, build, and refactor major software components
> handle multiple, sometimes conflicting priorities ... willingness to pitch in whenever necessary to get things done
Treating systems architecture with the same "ship it" mentality of product features is asking for a world of hurt.
Does it matter that dbt is written in Python? dbt models are still SQL at heart. Sure there's the addition of Jinja to enable references for data lineage and configuration, but it's all compiled to SQL with fine-grained control over what's produced.
Forgive me if I come across as combative, but I don't understand generic appeals to things like a language being rigorous. Rigorous to what end? What problem is it solving where that is required? If you know something specific in this domain where that level of rigor is needed, why not share what it is?
There are a lot of problems in the analytics space (and a lot of opportunity for new practices, tools, and businesses), but I would argue that at the end of the day the primary issue is whether or not data producers choose to model data such that it is legible outside of the system that produced it much more than it is about any particular language or methodology.
The most important word here is "sense" -- I don't think anyone can argue that the sense of individuality isn't real. But how much of our personal narratives are true, and how much of them do we make up to try and make sense of an otherwise chaotic existence? That isn't a fluffy philosophical musing; it's a core question of human psychology.
Some Buddhist teachings speak of "word sickness", where we spend so much of our lives living in abstractions that we are unable to experience the present moment as it actually is. We've drawn boxes around phenomena to try and classify everything, without realizing that we do this in ways that reinforce our own identities and sense of meaning in the world. We tend to treat the things we are good at as more important than the things we aren't, for instance. So how much of one's concept of self is really real, and how much has been invented to coalesce a sense of identity?
Is there any link between "open the kimono" and "comfort women" or is that conjecture?
It's a fascinating phrase, perhaps not least because nobody knows where it comes from but somehow people also seem to know that it's innocuous or know that it's sexist.
It's a very valid question. My personal opinion is that public media isn't by default better due to its ability to operate at a loss - in fact it could be argued that the only reason an administration would allow it to run at a loss is if it saw the operation as advantageous to its political objectives.
I think the real answer that nobody wants to hear is that media at this scale cannot exist without bad actors trying to manipulate it. There is no "web of trust" at the scale of millions.
> Yes some empires went away, but we still read writings from Ancient Greece, so is it correct to say even that civilization ended?
I get your point, but I think it misses the mark. By this measure, no civilization has ever ended. If you go that far, you have to argue that the end of a civilization is the same as the end of the human species.
I think it's helpful to think of it more like the end of the French revolution. No one can agree on a point in time when the revolution ended, but we all agree that it happened.
> Reversing the decline is a monster task — and one that some journalists and news organizations have taken upon themselves. They're going to need help — perhaps from America's CEOs.
Is this a bad joke? Distrust of media is largely brought about because it is (mostly) in the private sector and therefore always puts the sustainability of its business model above objective reporting. We've known for a while now that negative news sells, clickbait sells, and media organizations are all too happy to push it out there if it helps their struggling bottom line.
Isn't UNIX a clear example of people not engaging in architecture "astronaut" behavior? It was designed to be as simple as possible - in stark contrast to Multics.
> If a spouse wanted to sell their organs to improve the life of the remainder of their family, and made the choice with sound mind, then absolutely.
The thing is, nobody of sound mind who has a choice (and I mean a real choice, not "give us your organs or your family starves") would choose to do this.
Nobody wants to sell their organs. People that want to purchase organs would love your suggestion however, as it allows them to justify exploitation of the desperate under the guise of "it was their decision".
That's totally fine - but people need to also be aware that if something is really a must then they have to be willing to spend adequate time and resources on getting it done, instead of assuming whatever resources they have on hand will be sufficient.
It's amazing the things that stop being a "must have" as soon as they have to spend more money.
I always wondered how 3B1B makes the animations in his videos. Super pleased to see it's available as a Python library. Can't wait to play around with this!
Hi Mike! I really like what you've done with D3. I've been hesitant to include D3 in my personal projects though just because of how complex both DOM manipulation and async data binding through APIs can get.
Most tutorials focus on D3 itself, but I haven't been able to find much on how to properly integrate D3 into a complete web application (e.g. a REST API build on Express/Koa serving data to a React/Vue frontend). Is this an area where you think there is a lack of tooling, or perhaps simply a lack of information? Given how many companies use D3 I feel like I must be missing something!
- Don't use classes for information. Use regular data structures (dict, list, tuple, set) and use functions to manipulate them. If you really want/need something like a struct, use a dataclass.
- The itertools module has a bunch of useful constructs for creating and combining iterators. Take advantage of Python's iterators and construct your own when necessary.
- List comprehensions and generator expressions are great for clear and concise data transformations
- You're going to have to deal with state somewhere in your program. That's fine, some state is necessary to do real work. Don't feel bad about creating classes for things like context managers (e.g. for a database connection) so you can use it in a with statement and it will handle the setup and teardown logic for you. That way your business logic stays concise and Pythonic since those classes can be in separate modules and imported as necessary. I've found this 'functions in the front, classes in the back' approach to writing Python useful as it lets me think about what my program does in a functional manner without denying myself the ergonomics of Python's class-based ecosystem.