That comment sounds pretty benign to me. I also don't know why you're assuming the original commenter is male. The only person in the wrong here is you, and you're wrong twice over.
No, the point is that most people in this thread do not appreciate the complexity of implementing lazy imports. If you disagree, your energy is better spent talking to a CPython core developer about implementation details of making baseless assertions from an ivory tower.
There are many people here who think enabling lazy imports is as simple as flipping a light switch. They have no idea what they're talking about.
And actually people do appreciate the complexities of changes like this. We were responding to a specific comment that that said “it’s impossible”. Saying something is “possible” isn’t the same as saying “it’s easy”.
I’m not going to spend an entire weekend drafting a proposal instead of spending time with my kids, just to win “internet points”.
If you want examples then just look at one of the other languages that have implemented compiler / runtime dependency version checks.
Even Go has better dependency resolution than Python, and Go is often the HN poster child for how not to do things.
The crux of the matter is this is a solvable problem. The real issue isn’t that it’s technically impossible, is that it’s not annoying enough of a day to day problem for people who are in a position to influence this change. I’m not that person and don’t aspire to be that person (I have plenty of other projects on my plate as it is)
I also hope this proposal succeeds, but I'm not optimistic. This will break tons of code and introduce a slew of footguns. Import statements fundamentally have side effects, and when and how these side effects are applied will cause mysterious breakages that will keep people up for many nights.
This is not fearmongering. There is a reason why the only flavor of Python with lazy imports comes from Meta, which is one of the most well-resourced companies in the world.
Too many people in this thread hold the view of "importing {pandas, numpy, my weird module that is more tangled than an eight-player game of Twister} takes too long and I will gladly support anything that makes them faster". I would be willing to bet a large sum of money that most people who hold this opinion are unable to describe how Python's import system works, let alone describe how to implement lazy imports.
PEP 690 describes a number of drawbacks. For example, lazy imports break code that uses decorators to add functions to a central registry. This behavior is crucial for Dash, a popular library for building frontends that has been around for more than a decade. At import-time, Dash uses decorators to bind a JavaScript-based interface to callbacks written in Python. If these imports were made lazy, Dash would break. Frontends used by thousands, if not millions of people, would immediately become unresponsive.
You may cry, "But lazy imports are opt-in! Developers can choose to opt-out of lazy imports if it doesn't work for them." What if these imports were transitive? What if our frontend needed to be completely initialized before starting a critical process, else it would cause a production outage? What if you were a maintainer of a library that was used by millions of people? How could you be sure that adding lazy imports wouldn't break any code downstream? Many people made this argument for type hints, which is sensible because type hints have no effect on runtime behavior*. This is not true for lazy imports; import statements exist in essentially every nontrivial Python program, and changing them to be lazy will fundamentally alter runtime behavior.
This is before we even get to the rest of the issues the PEP describes, which are even weirder and crazier than this. This is a far more difficult undertaking than many people realize.
---
* You can make a program change its behavior based on type annotations, but you'd need to explicitly call into typing APIs to do this. Discussion about this is beyond the scope of this post.
Product manager for Dash here At Plotly we're actually pretty excited about the potential for lazy loaded imports, as it could help out a lot with the import performance of Plotly.py.
As this comment mentions Dash apps would not support lazy loaded imports until the underlying Dash library changes how it loads in callbacks and component libraries (the two features which would be most impacted here), but that doesn't mean there's no path to success. We've been discussing some ways we could resolve this internally and if this PEP is accepted we'd certainly go further to see if we can fully support lazy loaded imports (of both the Dash library itself/Dash component libraries and for relative imports in Dash apps).
They are not entitled to hold the opinion that their imports takes too long, if they dont know the inner workings of pythons import system? Do you listen to yourself?
Right now in python, you can move import statement inside a function. Lazy imports at top level are not needed. All lazy imports do is make you think less about what you are writing. If you like that, then just vibe code all of your stuff, and leave the language spec alone.
Ie, with lazy, the import happens at the site of usage. Since clearly this is code that could already be written, it only breaks things in the sense that someone could already write broken code. Since it is opt in, if using it breaks some code, then people will notice that and choose not to rewrite that code using it.
Some of these worries make sense, but wouldn’t it be relatively trivial to pass a flag to the interpreter or something similar in order to force all imports to evaluate, as in the current behavior? But to be a bit cheeky if some of these issues cause serious production outages for you it might be time to consider moving on from a scripting language altogether.
The issue is that some imports can be made lazy and some cannot. A binaristic all-or-nothing approach does not address the issue. (I also think that there is zero basis to claim that adding such a flag is trivial, since there’s no reference implementation of this flavor of lazy imports.)
What if we have a program where one feature works only when lazy imports are enabled and one feature only when lazy imports are disabled?
This is not a contrived concern. Let’s say I’m a maintainer of an open-source library and I choose to use lazy imports in my library. Because I’m volunteering my time, I don’t test whether my code works with eager imports.
Now, let’s say someone comes and builds an application on top of this library. It doesn’t work with lazy imports for some unknown reason. If they reach for a “force all imports” flag, their application might break in another mysterious way because the code they depend on is not built to work with eager imports. And even if my dependency doesn’t break, what about all the other packages the application may depend on?
The only solution here would be for the maintainer to ensure that their code works with both lazy and eager imports. However, this imposes a high maintenance cost and is part of the reason why PEP 690 was rejected. (And if your proposed solution was “don’t use libraries made by random strangers on the Internet”, boy do I have news for you...)
My point is that many things _will_ break if migrated to lazy imports. Whether they should have been written in Python in the first place is a separate question that isn’t relevant to this discussion.
Maybe the package that requires lazy can somehow declare that requirement, so another package that tries to force not lazy will fail early and realize it needs to replace this dependency with something compatible or change its ways. It definitely adds complexity, though.
Or check at runtime if it's running with the lazy import feature active. Then instead of breaking in mysterious ways in production it would crash on startup, during development.
Theoretically the implementation may use the approach "as lazy as possible". Traverse lazy imports until you encounter a regular one.
I doubt it will make much difference, but at least it gives an option.
I don't see how. It adds a new, entirely optional syntax using a soft keyword. The semantics of existing code do not change. Yes, yes, you anticipated the objection:
> What if these imports were transitive? ... How could you be sure that adding lazy imports wouldn't break any code downstream?
I would need to see concrete examples of how this would be a realistic risk in principle. (My gut reaction is that top-level code in libraries shouldn't be doing the kinds of things that would be problematic here, in the first place. In my experience, the main thing they do at top level is just eagerly importing everything else for convenience, or to establish compatibility aliases.)
But if it were, clearly that's a breaking change, and the library bumps the major version and clients do their usual dependency version management. As you note, type hints work similarly. And "explicitly calling into typing APIs" is more common than you might think; https://pypistats.org/packages/pydantic exists pretty much to do exactly this. It didn't cause major problems.
> Import statements fundamentally have side effects, and when and how these side effects are applied will cause mysterious breakages that will keep people up for many nights.
They do have side effects that can be arbitrarily complex. But someone who opts in to changing import timing and encounters a difficult bug can just roll back the changes. It shouldn't cause extended debugging sessions unless someone really needs the benefits of the deferral. And people in that situation will have been hand-rolling their own workarounds anyway.
> Too many people in this thread hold the view of "importing {pandas, numpy, my weird module that is more tangled than an eight-player game of Twister} takes too long and I will gladly support anything that makes them faster".
I don't think they're under the impression that this necessarily makes things faster. Maybe I haven't seen the same comments you have.
Deferring imports absolutely would allow, for example, pip to do trivial tasks faster — because it could avoid importing unnecessary things at all. As things currently stand, a huge fraction of the vendored codebase will get imported pretty much no matter what. It's analogous to tree shaking, but implicitly, at runtime and without actually removing code.
Yes, this could be deferred to explicitly chosen times to get more or less the same benefit. It would also be more work.
> Libraries such as PyTorch, Numba, NumPy, and SciPy, among others, did not seamlessly align with the deferred module loading approach. These libraries often rely on import side effects and other patterns that do not play well with Lazy Imports. The order in which Python imports could change or be postponed, often led to side effects failing to register classes, functions, and operations correctly. This required painstaking troubleshooting to identify and address import cycles and discrepancies.
This isn't precisely the scenario I described above, but it is a concrete example of how deferred imports can cause issues that are difficult to debug.
Regarding performance benefits:
> At Meta, the quest for faster model training has yielded an exciting milestone: the adoption of Lazy Imports and the Python Cinder runtime. ... we’ve been able to significantly improve our model training times, as well as our overall developer experience (DevX) by adopting Lazy Imports and the Python Cinder runtime.
Well not if you want high quality Python code. Pylint and Pyright won't understand it, and those are absolutely critical to writing Python code that works reliably.
Perhaps I'm not aware of the intricacies of Zig or AWS Lambda, but what is this library supposed to provide? It is well known that services written in two different languages can communicate with one another over HTTP (or TCP, or UDP, or whatever protocol we need to use to call into an AWS Lambda function).
It's not about Zig or AWS Lambda in particular, it's about being able to connect everything together. The goal is making those connections easier to create/test/maintain via my tool.
I've done it? I have a benchmark called scramblebench that will do rewriting to evaluate model performance degradation with symbol replacement and layers of indirection.
There is about as much ownership here as a squatter in a two-bedroom apartment. They are apologizing because they got caught, not because they genuinely believe they messed up.
No, I’m pretty sure Slack was never a “not for profit” company. Most not-for-profits do not ambush their customers with $250k bills on a week’s notice. I’ve seen debt collectors less predatory than this.
No I’m pretty sure they’re suggesting that the account got somehow flagged as a for profit account, and they consider that a mistake and are fixing it.
I think you don’t have to find the least charitable interpretation for what they’re saying. There can be something in the middle.
So if it were indeed a for-profit account, it would also be okay to give them just a couple of days to "find the money" or otherwise lose 11y of history?
I would guess that the issue came from losing the flag, and the disparity in amount owed built up over years, thus prompting the drastic action.
A company that had a for-profit account would likely not incur that much of a bill that quickly, so it wouldn't play out the same. I imagine there are a series of escalating collections steps, and the flag switch popped them right to the most extreme end.
Not sure if this works out, from my understanding the $50k would not even remotely cover a hypothetical for-profit categorization (should only cover less than 500 annual users, while my understanding is that Hack Club is significantly larger, by some orders of magnitude).
> least a dozen explanations less charitable than this one
Because you've already made up your mind that they're the bad guy, so it doesn't matter what really happened. One of the prevailing rules at HN used to be engage with the most charitable interpretation of an argument. It's always a better conversation when it's followed - this thread has just devolved into a bunch of pile-on virtue signaling with no actual interest in engaging honestly.
I don't perceive this as virtue signalling, this is your own slightly uncharitable interpretation. People are responding to what they perceive as bullying in line with what looks like extremely heavy-handee sales tactics that do not seem uncommon.
It also looks like it only got addressed because it hit a someone with enough traction to go viral. That they had to resort to this channel at all raises questions in itself that go beyond the initial mistake and this particular customer.
So while I agree that we do not know yet what actually happened, the response from Salesforce so far does not really address these all concerns, and is not inconsistent with less charitable views on what's going on.
I think this is rightfully getting called out. With big power comes big responsibility.
It's the literal definition of virtue signaling - a bunch of folks with zero context jumping to conclusions of evil and malicious intent to satisfy their own needs to join the pile-on comments and show how fake mad they are.
I see a thread of accusations and statements, not questions and engagement.
> It also looks like it only got addressed
The issue was less than two days old, in what world do you think a senior leader is going to learn of an issue like this in an org with 3,000 people? Most managers don't even get back to their direct reports in 24 hours, nonetheless getting a decision to someone higher up the ladder.
You seem to think people are responding here the way they are merely for social standing. At least, that's what virtue signaling is at its core, having looked at some definitions. I think people are upset at the actions of Slack/Salesforce and are responding accordingly. That would be a more organic or genuine motivation (for lack of a better word), while "virtue signaling" discounts the validity of people's responses and reduces them to a hollow show. That is why I called your interpretation uncharitable.
> The issue was less than two days old, in what world do you think a senior leader is going to learn of an issue like this in an org with 3,000 people?
We are commenting underneath a response by the CPO of Slack. There is a sibling comment by the CEO. I think they are aware.
People are calling them out on the things their resposes do not address, which I mentioned in my previous comment. It wouldn't even need to be answers to all the questions people have. The response could have included things like: this is not how we want to treat any of our customers; we will look into what went wrong and why; we will explain when we know and how we will try to prevent this from happening again.
That would have acknowledged the damage this issue does to the public perception of their business practices. Instead, they simply ignore all of that. Hence, people's reactions in here.
> We agree in spirit but not execution.
I agree that a lot of comments in here are quite emotional. I would be more wary if they were directed at a single individual acting in a personal capacity, instead of the representatives of a well-resourced corporation. The power imbalance matters a lot, and I think it makes a difference if someone rather more powerful is called out by more, rather than fewer, people.
Here's what I found for the definition - it perfectly captures 99% of the comments I'm reading.
"...the practice of conspicuously displaying one's good character, social conscience, or political alignment in order to gain praise, recognition, or social standing, often without taking meaningful action to support the cause one is professing to support".
People asking questions and attempting to engage are not virtual signaling, everyone else on their high horse throwing shade are doing exactly that. These comments are 100% pure worthless virtual signals that I expect to see on reddit, not HN.
> You seem to think people
I don't think, I know. Read the comments. No one here besides the original OP was impacted but everyone wants to pile-on and call them out with absolutely no real context while pulling conspiracy theories out of thin air and making statements about what must be true. I've seen very few actual posts where attempt to engage legitimately rather than some bullshit "gotcha!" comment.
> a response by the CPO of Slack
Yes, two days after the email was sent. Two days. Folks are whining that it wasn't "faster", that somehow these people are not reviewing every email that leaves the company. Worst case the OP wouldn't have paid, their Slack may have been disabled, and then when the CEO/CPO did find out the sales rep would have lost their job rather than what we're seeing here. But I believe that Slack would have done the right thing regardless.
> calling them out on the things their responses do not address
No most people are throwing accusations and making absolute statements of what they perceive to be truth. No one besides the original OP is entitled to a response from Slack, everyone else here is just using it as an opportunity to virtual signal. Why would anyone from Slack engage in this thread filled with hostility and zero lack of desire to understand what happened, because they're so convinced they already have the answer? These posters are tourists using this as an opportunity to show off how mad they are, not customers that deserve a response.
This thread is an embarrassment to the HN community, and we can go back years and find similar situations where company screwed up and will not find the vitriol found here.
Oh yes, people could be more level-headed and write more level-headed comments instead of emotional knee-jerk ones. But you know what? In this thread, you are one of them.
I read what you wrote and I see pre-conceived notions about what is or is not going on at Slack, about the motivations of your fellow commenters and the worth of their contributions, no openness, but dismissal wrapped in an increasingly generous portion of vitriol. Take a look at your words, and tell me you're not even outdoing many of them. It's just your sympathies are aligned differently.
That in turn annoys me. Some part of me really wants to blame you, but I actually don't. What'd be the point? We're just getting caught up in this crap. I get it, it's frustrating! I'm frustrated, you sound frustrated, and if you want to give them that, the people you are complaining about are frustrated, too.
Isn't it interesting how these things perpetuate themselves in online discussions? Somebody manages to piss us off, and the first reflex is to piss right back. Does it make anybody feel better? No. It sucks.
So yeah, this thread is not a great example of the good aspects of humanity. Let's not perpetuate it. Let's do better. Let's do something nice. It's fall here, the leaves are turning red. There's the possibility of cake. Hopefully there's something pleasant waiting for you, too. I wish you a nice Sunday, wherever you are.
The fact of the matter is that Slack knew they were a nonprofit and made the deliberate decision to engage in the SaaS equivalent of rent-seeking. This is honest engagement, and given the circumstances I think people in this thread have been incredibly charitable.
"Slack" didn't know anything. Slack isn't a human being. Like somehow everyone that joins the company connects a collective consciousness with shared memory.
> deliberate decision to engage in the SaaS equivalent of rent-seeking
Clearly you were involved in the process and have fist-hand knowledge to be so confident lol. The crazy absurdity of everyone being so convinced of the conspiracy theories they've pulled out of their asses.
> given the circumstances I think people in this thread have been incredibly charitable.
I don't think that word means what you think it means.
