In the improved error message [0] how are they able to tell nested attributes without having a big impact in performance? Or maybe this has a big impact on performance, then using exceptions for control flow is deprecated?
...
print(container.area)
> AttributeError: 'Container' object has no attribute 'area'. Did you mean: 'inner.area'?
> using exceptions for control flow is deprecated?
Exceptions are for the exceptional cases - the ones that mean normal operations are being suspended and error messages are being generated. Don't use them for control flow.
In Python, an iterator raises a StopIteration exception to indicate to the for loop that the iterator is done iterating.
In Python, the VM raises a KeyboardInterrupt exception when the user hits ctrl+c in order to unwind the stack, run cleanup code and eventually exit the program.
Python is a quite heavy user of exceptions for control flow.
Typically yes, but not in Python. In Python it is quite common and accepted, and sometimes even recommended as Pythonic to use exceptions for control flow. See iterators, for example.
Using exceptions for flow control has always been a bad idea, despite what they might have said. Perhaps they are generating that message lazily though?
On the other hand it's not like Python really cares about performance....
All iterators in Python use exceptions for flow control, as do all context managers for the abort/rollback case, and it is generally considered Pythonic to use single-indexing (EAFP) instead of check-then-get (LBYL) - generally with indexing and KeyError though and less commonly with attribute access and AttributeError.
[heavy green check mark]
try:
data = collection['key']
except KeyError:
data = ..try something else..
[red x]
if 'key' in collection:
data = collection['key']
else:
data = ..try something else..
The latter form also has the genuine disadvantage that nothing ensures the two keys are the same. I've seen typos there somewhat often in code reviews.
Last time I measured it, handling KeyError was also significantly faster than checking with “key in collection.” Also, as I was surprised to discover, Python threads are preemptively scheduled, GIL notwithstanding, so it’s possible for the key to be gone from the dictionary by the time you use it, even if it was there when you checked it. Although if you’re creating a situation where this is a problem, you probably have bigger issues.
If valid `data` can be zero, an empty string, or anything else “falsy”, then your version won’t handle those values correctly. It treats them the same as `None`, i.e. not found.
No, this would crash with numpy arrays, pandas series and such, with a ValueError: The truth value of an array with more than one element is ambiguous.
> All submissions must come from verified individuals or organizations. Inside the OpenAI Platform Dashboard general settings, we provide a way to confirm your identity and affiliation with any business you wish to publish on behalf of. Misrepresentation, hidden behavior, or attempts to game the system may result in removal from the program.
Remember when Sam Altman went around the world scanning people's irises with an orb-like object, to differentiate them from future AI, in exchange for fake money?
"Your privacy is very important _for us_"
It is to protect against terrorists. And to protect the children.
If it works for Google, why shouldn't work for them.
> The logo is further on the left than the other icons.
But why the logo of the website/app should be aligned with the icon of the actions?
> The icons are thin, compared to the text, which is bold.
Why this is an issue?
I can somewhat agree with the other points, but I wouldn't call this "bad design." Just because the information can sometimes be presented better doesn't mean the previous way was bad.
Whenever I read some of these design articles, I usually see this same glaring issue. Without any distinction, they'll present together a grab bag of objective facts, best practices, and simple conventions.
There's nothing objective about using ctrl+s for save, but it's an obvious best practice. So not following can be considered bad design fairly uncontroversially.
The two you mentioned are obviously not in that category. I take issue with the logo one especially, because I find the style of the "bad design" better and more functional.
>[...] I’m probably the only one who noticed that it’s calmer.
I hope you will get further sponsorships so you can continue your cool work in the FOSS space.
I also totally agree that uv makes shipping python software smoother. Prior to uv I hesitated to use Textual to build cool TUIs for internal tools. But now, it’s a totally different story. I wish I had an internal tool to write with Textual right now.
Maybe by the time Toad is officially out, I will have a project ready to dive into.
I also prefer the mental model of immediate mode, but when I played with Dioxus[0] for a rust fullstack hobby project[1], I was able to adapt.
I liked the DX with the tools and the `rsx!` macro. The use of `#[cfg(feature = "server")]` to define server-side code is interesting, it lets you keep a shared codebase for frontend and backend, while still controlling what gets compiled to WASM for the client.
I agree, the latest models are not bad at Rust. Most issues I have when writing LLM-assisted Rust code are related to dependencies.
There are a lot of v0.x.x crates in Rust with frequent updates and breaking changes. As LLMs "learn" from code in the wild, they are exposed to different way to use the same crate and thus fail to produce working code "from memory".
But as soon as you explain how to use it with the latest syntax, they are able to fix the code.
[0] -- https://docs.python.org/3.15/whatsnew/3.15.html#improved-err...
reply