Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python 3.12

python.org

Post reply on HN
Print view View original

291–300 of 344 posts

Re: Python 3.12

#291

Post by shpx »

karlicoss wrote: post #225
xavdid wrote: post #216

Earlier quoted context omitted.

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.

From my looking around, Homebrew's Python 3.11 has specific binaries for each macOS and CPU architecture

https://github.com/Homebrew/homebrew-core/blob/c1321e2629203...

A comment in Homebrew's formula says that Homebrew adds the --enable-optimizations flag during compilation because Homebrew has separate binaries whereas the official Python release doesn't add this flag because "they want one build that will work across many macOS releases"

https://github.com/Homebrew/homebrew-core/blob/c1321e2629203...

and it looks to me that pyenv just installs the official binary

https://github.com/pyenv/pyenv/blob/28e7000b485bff61235d8a69...

So I would expect it to be the other way around, Homebrew's Python should be faster.

Re: Python 3.12

#292

Post by magarnicle »

throw1234651234 wrote: post #252

Oh hey, the useless (except for leetcode) language got an update. Yay, maybe more people try to write boring business logic without type safety. Can't wait.

Weird, apparently all those things I've got done with Python didn't actually get done. I was just imagining it.

Re: Python 3.12

#293

Post by freediver »

nickdrozd wrote: post #142

Running my project's computation-intensive test suite takes 83 seconds under 3.11 and 67 seconds under 3.12. That's a pretty good improvement!

I was not able to reproduce and speed improvements over 3.11.

Re: Python 3.12

#294

Post by [deleted] »

0xFF0123 wrote: post #272
lvass wrote: 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 what aspect of the poem you don't think will be relevant in a century from now?

[deleted]

Re: Python 3.12

#295

Post by extraduder_ire »

godelski wrote: post #276
brenns10 wrote: post #262

Earlier quoted context omitted.

I love and use rich too, but gosh I hope that libraries don't start depending on it just because pip does. It has a lot of dependencies of its own, and dependency creep is real. I know pytorch isn't exactly lightweight in terms of dependencies. But I prefer using libraries that make an effort do only pull in absolutely necessary dependencies.

Yeah sorry I don't think I was clear. I don't exactly want to just drop in rich into the python source (for reasons you mention). But I do think they could take some of the ideas from there and place them in. Formatting is really the most important aspect here, especially around traces because these are the real work amplifiers. So much time is spent debugging that the better tools we have to debug better the more wo…

Would there be any way to inject such formatting in by messing with the interpreter at runtime? I assume it would be possible to get as far as "works most of the time" and "doesn't create too many additional problems".

Re: Python 3.12

#296

Post by benkuykendall »

dagmx wrote: post #209
squeaky-clean wrote: post #168

Earlier quoted context omitted.

The type that gets Unpack[]'d needs to inherit from TypeDict, unless I'm misunderstanding what you mean.

Basically I was hoping to use it for functions that wrap others. E.g setup something and then pass the kwargs through to the other function.

If I understand you correctly, I think ParamSpec (since 3.10) is what you are looking for, especially if you want to be generic over the type of the inner function. The example from the docs (https://docs.python.org/3/library/typing.html#typing.ParamSp...):

  from collections.abc import Callable
  from typing import TypeVar, ParamSpec
  import logging
  
  T = TypeVar('T')
  P = ParamSpec('P')
  
  def add_logging(f: Callable[P, T]) -> Callable[P, T]:
      '''A type-safe decorator to add logging to a function.'''
      def inner(*args: P.args, **kwargs: P.kwargs) -> T:
          logging.info(f'{f.__name__} was called')
          return f(*args, **kwargs)
      return inner
  
  @add_logging
  def add_two(x: float, y: float) -> float:
      '''Add two numbers together.'''
      return x + y

Re: Python 3.12

#297

Post by shrimpx »

wiseowise wrote: post #283
shrimpx wrote: post #258

Earlier quoted context omitted.

> disaster of an anti-feature Untyped languages tend to be at the forefront of paradigms, and typed languages come in toward the end when reliability and need for tooling are more important than innovation/discovery. In the 90s a bunch of kids were building websites with LAMP stacks while serious engineers were building aging/about-to-be-irrelevant desktop software in serious, typed languages.

Guess on VM written in which language those LAMP stacks run on?

Sure. The “serious” stuff is written in more serious languages and the rapidly changing experimental stuff in more lenient and expressive languages.

Re: Python 3.12

#298

Post by shrimpx »

blacklight wrote: post #290
shrimpx wrote: post #258

Earlier quoted context omitted.

> disaster of an anti-feature Untyped languages tend to be at the forefront of paradigms, and typed languages come in toward the end when reliability and need for tooling are more important than innovation/discovery. In the 90s a bunch of kids were building websites with LAMP stacks while serious engineers were building aging/about-to-be-irrelevant desktop software in serious, typed languages.

I love Python, but I also love the ability to tell what is what. I kickstarted a project in Python a decade ago that was wild on dynamic typing. As it passed a critical threshold of ~10k LoC, it became nearly ummaintainable. What's that `response` passed here? A verbatim response object from `requests`? A proxy mapping? Bytes? A JSON string? If so, a list or a dict? And what fields are inside? Multiply it by tens or…

I agree. And what makes python a nice choice for this is that you can go wild in the beginning and then gradually add type hints as your project takes shape.

Re: Python 3.12

#299

Post by SushiHippie »

kuratkull wrote: post #226
tandav wrote: 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.

You can use it since 3.7 with `from __future__ import annotations`

Re: Python 3.12

#300

Post by godelski »

extraduder_ire wrote: post #295
godelski wrote: post #276

Earlier quoted context omitted.

Yeah sorry I don't think I was clear. I don't exactly want to just drop in rich into the python source (for reasons you mention). But I do think they could take some of the ideas from there and place them in. Formatting is really the most important aspect here, especially around traces because these are the real work amplifiers. So much time is spent debugging that the better tools we have to debug better the more wo…

Would there be any way to inject such formatting in by messing with the interpreter at runtime? I assume it would be possible to get as far as "works most of the time" and "doesn't create too many additional problems".

Like how the rich logging handler works? Or something different? You can definitely write custom handlers for python loggers. Pytorch is a bit more of a pain though.
Post reply on HN