The CSU/CDU Union party (from which Merz comes) has been, at least in recent historical time, consistently pro-nuclear (at least in terms of their actions). They have consistently voted to lengthen contracts with nuclear providers and consistently advocated for pro-nuclear policies, even when the power companies themselves had long since committed to ceasing all nuclear power production in Germany.
Additionally, the exit out of nuclear power was decided following public outcry after Fukushima -- ie, still squarely within the Merkel government. Merz has been consistently anti-Merkel.
So put into context, the article is saying "the current chancellor of Germany, Merz, thinks leaving nuclear behind was a strategic mistake!" while ignoring "whose party has consistently been pro-nuclear, whose predecessor, who (by the way) Merz doesn't like and frequently and loudly disagrees with, only presided over the decade-long phase-out in response to public outcry following a major nuclear disaster".
IMO this is about as newsworthy as what he ate for breakfast.
I mean, for retail investors outside the US, the question you're asking boils down to „does purchasing power parity follow popular US domestic market indices?“, to which the answer is a resounding no.
There may be some offset for goods imported from the US, but that's a minority of consumer goods globally, and even then, the purchase currency will usually still be the local fiat, and then the attractiveness of the US index fund still has to be weighed against the performance of non-US-based indices in that same local currency as opportunity cost.
Putting aside, for a moment, a lot of important questions around (gestures broadly at the political situation in the US), what are the economic implications of a conflict between the US and Venezuela?
Is this likely to increase inflation? And what does this mean for FX -- are we likely to see a further weakening of the dollar, particularly against ex EUR?
Certainly for many applications, the autoint approach would be fine.
The benefit of uuid in this case is that it allows horizontally scalable app servers to construct PKs on their own without risk of collisions. In addition to just reducing database load by doing the ID generation on the app server (admittedly usually a minor benefit), this can be useful either to simplify insert queries that span multiple tables with FK relationships (potentially saving some round trips in the process) or in very niche situations where you have circular dependencies in non-nullable FKs (with the constraint deferred until the end of the transaction).
I'm also not a huge fan of leaking server-side information; I suspect UUIDv7 could still be used in statistical analysis of the keyspace (in a similar fashion to the german tank problem for integer IDs). Also, leaking data about user activity times (from your other comment) is a *really* good point that I hadn't considered.
I've read people suggest using a UUIDv7 as the primary key and a UUIDv4 as a user-visible one as a remedy.
My first thought when reading the suggestion was, "well but you'll still need an index on the v4 IDs, so what does this actually get you?" But the answer is that it makes joins less expensive; you only require the index once, when constructing the query from the user-supplied data, and everything else operates with the better-for-performance v7 IDs.
To be clear, in a practical sense, this is a bit of a micro-optimization; as far as I understand it, this really only helps you by improving the data locality of temporally-related items. So, for example, if you had an "order items" table, containing rows of a bunch of items in an order, it would speed up retrieval times because you wouldn't need to do as many index traversals to access all of the items in a particular order. But on, say, a users table (where you're unlikely to be querying for two different users who happen to have been created at approximately the same time), it's not going to help you much. Of course the exact same critique is applicable to integer IDs in those situations.
Although, come to think of it, another advantage of a user-visible v4 with v7 Pk is that you could use a different index type on the v4 ID. Specifically, I would think that a hash index for the user-visible v4 might be a halfway-decent way to go.
I'm still not sure either way if I like the idea, but it's certainly not the craziest thing I've ever heard.
For those that can't get it to load (it takes a minute, and I noticed my desktop's fan kick it up a notch while things were getting initialized, so... YMMV): this is a portfolio site done via a cozy-gaming-style AWSD game where you drive around in a jeep-like thingamabob. There are some cute easter eggs, including a sort of... shrine to each of the socials, which you can run into with your car and knock over (though the links remain clickable, of course!). It also looks like there's some degree of global state; for example, you can "sacrifice yourself to the gods of chaos" (ie drive into a portal) and a counter on the side of the portal goes up, presumably for everyone (since I certainly didn't drive into it 1700 times myself!). There's a strongly consistent art style, and just generally... seems pretty polished. Or at least, that's what it felt like after 5 minutes of driving around.
All in all I'd say, I'm impressed, and enjoyed it. Though I think the HN title ("handsdown one of the coolest 3D websites") is maybe a bit much. It's an extremely-well-executed portfolio site; no more, no less.
> I didn't mean that you could 3-D print tiny laparoscopes or even visible-light metamaterials; I meant that you could 3-D print machines for making tiny laparoscopes and visible-light metamaterials.
Huh, thanks for the clarification, that's an angle I hadn't considered.
> I think you're overlooking the part of the iceberg that's currently below the waterline of economic feasibility.
Hm. I think to a degree you probably have a point; I certainly agree that people tend to overlook the explosion of new development that is made possible by drastic cost reductions, though with the aside that having price insensitive applications is often instrumental in developing the technology that enables those cost reductions in the first place, because it allows for profitability early on in the technology's maturation, as opposed for "well it won't be profitable until we hit X milestone in Y years".
That being said, it's not clear to me how many mass-market biological applications would be possible under reasonable regulatory regimes. Maybe I'm just showing my ignorance when it comes to small-scale biological applications, but can you name some examples? (Or is this more of a "you never know until somebody does it" kind of thing?)
I'm not trying to say that there aren't plenty of applications for small scale mechanical devices, but rather that the applications where FDM-style 3d printing would be an appropriate manufacturing process are likely to be largely biological.
Biological applications (of which tooth and bone would of course be included) are extremely well-suited for additive manufacturing because they're frequently one-offs, and therefore cannot scale, and oftentimes highly insensitive to price. Mass market products are a whole different ball game; even for applications where there isn't currently an economical manufacturing method, I'm very skeptical that there's a path where AM could be scaled out to the volumes required to sell the end component at a commercially viable cost.
To be fair though, I didn't do a good job expressing that, because I just took it for granted that it would be clear that large ratios between feature size and nozzle size are rarely economical for FDM-style AM, which isn't necessarily an obvious observation.
From TFA, they're using it to print bioinks. Think scaffolding for cell cultures.
At these kinds of physical scales, biology is almost certainly a much larger market than mechanical applications. A 20 um line width (slightly less than one thou for US folks) is certainly a tolerance you might encounter on a drawing for subtractive manufacturing, but for addative, feature sizes that small will be strength limited.
Having used both extensively, Geizhals doesn't hold a candle to McMaster. McMaster is, bar none, the single best e commerce website I've ever used (if you already know what you're looking for, and definitely still top shelf if you don't).
But McMaster and eg Amazon are optimizing for different things. McMaster knows its clientele isn't going shopping, they're solving problems. As such, McMaster focuses on helping your solve your problem and get back to work. Amazon, on the other hand, is focused on just selling you "as much 'anything' as possible" and wants you to spend as much time there as possible in the hopes that you'll stumble on an impulse buy.
In that case I'd opt for dynamic module creation using metaprogramming instead of an import hook. And I personally would argue that grabbing the code objects from module members and re-execing them into a new module object to re-bind their globals is simpler than an AST transformation.
But regardless of the transformation methodology: the import hook itself is just a delivery mechanism for the modified code. There's nothing stopping the library from using the same transformation mechanism but accessing it with dynamic programming techniques instead of an import hook. And there's nothing you can't do that way.
If you only want your own code to see the patch, then why not just wrap it?
I mean if you really need super strong isolation, you can always create a copy of the library object; metaprogramming, dynamic classes, etc, all make it really easy to even, say, create a duplicate class object with references to the original method implementations. Or decorated ones. Or countless other approaches.
My point isn't that I don't see problems that could be solved by this; my point is that I can't think of any problems that this solves, that wouldn't be better solved by things that don't do any innards-fiddling in what is arguably the most sharply-edged part of python: packaging and imports.
And speaking from experience... if you think patching can fail in subtle edge cases, then I've got some bad news for you re: import hooks.
At the end of the day, people who might use this library are looking for a solution to a particular problem. When documenting things, it's really important to be explicit about the pros and cons of your solution, from the perspective of someone with a particular problem, and not from the perspective of someone who's built a particular solution. If I need to drive a nail, and you're selling wrenches, I don't want to hear about all of the features of your wrenches; I want to know if your wrench can drive my nail, and why I would ever want to choose it instead of a hammer.
I can think of a lot of differently-shaped metaphorical nails that fall under the broad umbrella of "I need to change some upstream code but don't want to maintain a fork". And I can think of a whole lot of python-specific specialty hammers that can accomplish that task. But I still can't think of a signle situation where using import hooks to solve the problem is doing anything other than throwing a wrench into a very delicate gearbox. That is the explanation I would need, if I were in the market for such a solution, to evaluate modshim as a potential approach.
If the goal is to actually package and distribute the changes via import hook, that makes the supply chain attack question particularly relevant. And it still doesn't explain why you couldn't just package and distribute the monkeypatch itself, instead of creating a whole new import ecosystem surrounding hooks.
I've done my fair share of that too, but I'm still not seeing the benefit vs patching.
For context: one of the several projects I'm working on right now is an automated extraction system for literate-code-style documentation in python. This isn't the place nor time to talk about the why of it (especially compared to other existing similar solutions). The important thing is the how: it uses a temporary import hook to stub out all module imports, allowing the docs generator to process each module independently at runtime, track imports between them, etc. At the end of the process, it also cleans itself up nicely.
Point being, it's a lot of really complicated fiddling with the python import system. And a lesson I have learned is that messing around with import internals in python is extremely tricky to get right. Furthermore, trying to coordinate correctly between modules that do and don't get modified my the hook is very finicky. Not to mention that supply side attacks on the import system itself could be a terrifying attack vector that would be absurdly difficult to detect.
All this to say, I'm not a big fan of monkeypatching, but I know exactly how it behaves, its edge cases, and what to expect if I do it. It is, after all, pretty standard practice to patch things during python unit tests. And even with all its warts, I would prefer patching to import fiddling any day of the week and twice on Sunday.
Feedback for the author: you need to explain the "why" of your project more thoroughly. I'm sure you had a good reason to strike out in this direction, and maybe this is a super elegant solution. But you've failed to explain to me under what circumstances I might also encounter the same problems with patching that you've encountered, in order to explain to me why the risk of an import hook is justified.
IMO, the trick to really enjoying python typing is to understand it on its own terms and really get comfortable with generics and protocols.
That being said, especially for library developers, the not-yet-existant intersection type [1] can prove particularly frustrating. For example, a very frequent pattern for me is writing a decorator that adds an attribute to a function or class, and then returns the original function or class. This is impossible to type hint correctly, and as a result, anywhere I need to access the attribute I end up writing a separate "intersectable" class and writing either a typeguard or calling cast to temporarily transform the decorated object to the intersectable type.
Also, the second you start to try and implement a library that uses runtime types, you've come to the part of the map where someone should have written HERE BE DRAGONS in big scary letters. So there's that too.
So it's not without its rough edges, and protocols and overloads can be a bit verbose, but by and large once you really learn it and get used to it, I personally find that even just the value of the annotations as documentation is useful enough to justify the added work adding them.
This is a really clear picture of things, thanks! I am actually originally from the US, but I've been living in the EU for 5ish years and haven't had a car since I gave the one I had in college back to my parents after I moved to the bay area, where public transit was good enough that I couldn't really justify the ongoing expense for something I was just using for grocery runs. Otherwise, I've just been purchasing motorcycles in cash.
I guess I'd never really seriously considered the availability of loans for used cars (beyond the unsecured personal loans); it makes sense that they would exist, but in the ~30 years I lived in the states, I never once heard mention of them, or talked to anyone who had gotten one. Which is pretty crazy if you think about it. I think that, combined with the complete and total lack of regulation surrounding private sales (ie, no way for banks to de-risk the loan), made me assume they just weren't a thing. So I stand corrected.
But I think your anecdote might offer an even more compelling reason why: to satisfy the conditions to actually get one, you find yourself in territory where, from a short-term month-to-month financial perspective, you might as well just be buying new. And if you're struggling to make ends meet... welp, that's that.
The credit score is another good point; it might also be the case that the people who have a good enough credit score to land a decently-priced financing deal on a used car are almost by definition financially capable of buying new. Where I grew up, there was definitely a stigma against buying used, so that seems like it might also have some explanatory power.
Additionally, a lot of people who would otherwise be in the used car market for price reasons in the US cannot afford to purchase even a used car outright, and getting financing for cars sold on the private market is, to my knowledge, not really possible.
Certificate transparency logs are likely the only realistic way, but you could make the same argument against your DNS provider. Trust has to start somewhere.
Whether or not something like this makes sense to you is probably a question of your personal threat model.
The CSU/CDU Union party (from which Merz comes) has been, at least in recent historical time, consistently pro-nuclear (at least in terms of their actions). They have consistently voted to lengthen contracts with nuclear providers and consistently advocated for pro-nuclear policies, even when the power companies themselves had long since committed to ceasing all nuclear power production in Germany.
Additionally, the exit out of nuclear power was decided following public outcry after Fukushima -- ie, still squarely within the Merkel government. Merz has been consistently anti-Merkel.
So put into context, the article is saying "the current chancellor of Germany, Merz, thinks leaving nuclear behind was a strategic mistake!" while ignoring "whose party has consistently been pro-nuclear, whose predecessor, who (by the way) Merz doesn't like and frequently and loudly disagrees with, only presided over the decade-long phase-out in response to public outcry following a major nuclear disaster".
IMO this is about as newsworthy as what he ate for breakfast.