Earlier quoted context omitted.
A big use case for kwargs is not breaking compatibility and not having to copy/paste a ton of parameters when just forwarding them. But that's exactly the case which is difficult to type correctly.
Either copy/paste or rolling them into config objects and passing those down is generally preferable. Copy paste doesn’t always feel great for pass through arguments but it’s perfectly interpretable. Naked kwargs is so difficult to work with that I hesitate to think of a use case where it wouldn’t be an anti pattern.
Python 3.12
221–230 of 344 posts
Re: Python 3.12
#222Earlier quoted context omitted.
Finally! I've been waiting for this for years. Now I just have to wait 5 more years until 3.12 is sufficiently old that work lets me use it. Bets on user-upgradable Python on Linux by 2030?
Software is always user-upgradable on Linux. Just install it somewhere in your home directory. GNU Stow [0] can be helpful as a very lightweight way to manage the packages. (Of course, then you take on the responsibility of keeping up with patch releases yourself, which is why we use distros. But if it's just a small number of packages on top of a distro-managed base system, it's perhaps not so bad.) [0] https://www.…
Re: Python 3.12
#223Earlier quoted context omitted.
I'm not sure how to interpret these lines in a way that doesn't suggest support for unchecked immigration: > Do not be so stupid to think that > A place should only belong to those who are born there >... > It is not okay to say > Build a wall to keep them out
I'm guessing you're not an American by this comment, at least from the US >Do not be so stupid to think that >A place should only belong to those who are born there Does not imply unchecked migration since the entire social fabric of the United States is a based upon people moving here from somewhere else. Currently around 14% of US citizens are foreign born. Claiming they don't belong here would be considered an ext…
Re: Python 3.12
#224As now f-strings can contain any valid Python expression inside expression components, it is now possible to nest f-strings arbitrarily: >>> f"{f"{f"{f"{f"{f"{1+1}"}"}"}"}"}" '2' Is anyone aware of the change to the interpreter that allows for this?
> When f-strings were originally introduced in PEP 498, the specification was provided without providing a formal grammar for f-strings. Additionally, the specification contains several restrictions that are imposed so the parsing of f-strings could be implemented into CPython without modifying the existing lexer. [...]
> The other issue that f-strings have is that the current implementation in CPython relies on tokenising f-strings as STRING tokens and a post processing of these tokens. This has the following problems: [...]
At https://peps.python.org/pep-0701/#rationale
> By building on top of the new Python PEG Parser (PEP 617), this PEP proposes to redefine “f-strings”, especially emphasizing the clear separation of the string component and the expression (or replacement, {...}) component.
Re: Python 3.12
#225Not yet available through Homebrew. But this link will go live when it is: https://formulae.brew.sh/formula/python@3.12
pro tip: don't install user python using homebrew; use a dedicated version manager (like pyenv or adsf). More info: https://justinmayer.com/posts/homebrew-python-is-not-for-you...
Re: Python 3.12
#226I wish they make it possible to use any, callable builtins for type annotations
def foobar(things: list[tuple[int, Floob | None]]) -> dict[int, int]):
Possible since 3.11 I think, maybe even 3.10.
Re: Python 3.12
#227Re: Python 3.12
#228Everything aside, I enjoyed the "And now for something completely different" part.
Great! Hadn’t seen that initially. That’s what I adore about truly open source projects such as Python, but also Linux or Rust, for example. They’re not polished products of faceless corporations. They have rough edges, as everything does, and that’s okay. And time and again some human spirit shines through, like it does here. A welcome reminder we’re all in this together, and that next quarter’s shareholder revenue…
Most corporation products are absolutely horrible comparing to Python, the polished ones you know of are few exceptions. I've seen a few internal programming languages and anything publicly known is ... at least usable.
Re: Python 3.12
#229What's new: https://docs.python.org/dev/whatsnew/3.12.html Summary, sorry for poor formatting, I'm not sure HN can do a list of any kind? New features More flexible f-string parsing, allowing many things previously disallowed (PEP 701). Support for the buffer protocol in Python code (PEP 688). A new debugging/profiling API (PEP 669). Support for isolated subinterpreters with separate Global Interpreter Locks (PEP 684…
Isolated subinterpreters (PEP 684): Just how isolated are those? Is it simply a more complicated version of multiprocessing, with all the same drawbacks (communication via pipes/socket/some-other-stream)?
It's basically web workers / isolates for Python.
Re: Python 3.12
#230Earlier quoted context omitted.
I dislike it because it's kinda hard to understand (can't really say I did) specially without any context, and programming language release notes are something people should read even a hundred years afterwards.
I'm curious about the circumstance leading to reading Python 3.12 release notes in 2123.