Live data from Hacker News

Python 3.12

python.org

221–230 of 344 posts

Re: Python 3.12

#221

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.

There's at least a handful of places that you can't escape them, one of the most evident in my mind is when constructing higher order functions or other decorators. Maybe a simple example would be a retry higher order function (or decorator), where you can't know the arguments and their form ahead of time, and want to invoke the wrapped function as is (and only do something like repeating if an exception is triggered). Keyword arguments are helpful for writing certain kinds of generic code, but definitely can be easily abused (much like most of the meta-programming facilities in Python).

Re: Python 3.12

#222
post #208

Earlier 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.…

Sure and how do you install Python 3.12 on RHEL 8 without compiling it from source?

Re: Python 3.12

#223

Earlier 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…

That's fair. I interpreted "no walls" as "open borders" but you're right that there are ways of enforcing limitations on immigration that aren't physical barriers at the border.

Re: Python 3.12

#224

As 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?

At https://peps.python.org/pep-0701/#motivation

> 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

#225
post #216

Not 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...

Another thing I noticed is that homebrew python was noticeably slower on M2 comparing to the pyenv one. I imagine homebrew compiles it with too generic flags to support wide range of macs.

Re: Python 3.12

#226
post #217

I wish they make it possible to use any, callable builtins for type annotations

You can.

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

#228
post #5

Everything 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…

> 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

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

#229

What'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 a less complicated version of multiprocessing because you don't have to deal with multiple processes and all the complexity that that entails.

It's basically web workers / isolates for Python.

Re: Python 3.12

#230
post #119

Earlier 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.

We have Fortran code from several decades ago defining scientific domain knowledge. The next Einstein formula may require 3.12 to run.
Post reply on HN