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

Python 3.15: features that didn't make the headlines

blog.changs.co.uk

Post reply on HN
Print view View original

81–90 of 236 posts

Re: Python 3.15: features that didn't make the headlines

#81

Post by sunshine-o »

surajrmal wrote: post #65
sunshine-o wrote: post #48

I am not a python dev but have the utmost respect for the ecosystem. But damn, with all the supply chain attacks now in the news, could they just make a simple way (for non python insiders) to install python apps without fearing to be infected by a vermin with full access to my $HOME ...

There is little that they can do short of running the programs in a VM. Linux distros aren't engineered to consider applications as something different from the user running them. You need a completely different security model to achieve that and the Python runtime isn't tackle that.

In its inception 35 years ago the creator of python could not foresee how far python would go and how the environment would look like today. But nowadays there are a lot of security mechanisms they could leverage to adapt (from chroot by default to namespaces, cgroup, etc. on Linux, pledge, unveil on OpenBSD).

The very idea that you offer a (python) package installer that is gonna pull a tree of code published and updated by random people in an unvetted manner open the door to all the supply chain attacks we are seeing.

Around the same time (early 90s) Java was designed with high isolation in mind but the goal and vision was very different. And Java had its own problems.

I'm saying that because at some point the security problem is gonna really hurt the python ecosystem.

Re: Python 3.15: features that didn't make the headlines

#82

Post by 1_08iu »

IshKebab wrote: post #56
BOOSTERHIDROGEN wrote: post #27

Earlier quoted context omitted.

Interested in why you'd use Python in the first place? Advice for someone who knows nothing about programming - what would you suggest?

IMO the main reasons people use Python are: 1. The very first steps are quite simple. Hello world is literally just `print("hello world")`. In other languages it can be a lot more complex. 2. It got a reputation as a beginner-friendly language as a result. 3. It has a "REPL" which means you can type code into a prompt and it will execute it interactively. This is very helpful for research (think AI) where you're tryi…

I think "Python is slow" is reductive and frankly just as useful as saying "Python begins with a 'P'". The story is more complicated than simply speed of execution.

Choosing a language is a game of trade-offs: potentially slower execution in return for faster development time, for example. If your team is already familiar with Ruby, will asking them to write a project in Rust necessarily result in a better product? Maybe, but it will almost certainly take much longer.

Anyway, how many Python programs are actually "too slow"? Most of the time, Python is fast enough, even if heavy computation is offloaded to other languages.

As for Rust being the best language of them all, that's, like, your opinion, man.

Re: Python 3.15: features that didn't make the headlines

#84

Post by assbuttbuttass »

kokada wrote: post #43
saghm wrote: post #38

Earlier quoted context omitted.

This seems a lot more due to an import running arbitrary code because stuff can happen in the top-level of a module rather than only happening in functions. From what I can tell, it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones, which tend to have a main function that everything else happens inside transitively. I guess this makes it easy if what you're…

> it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones Counter-example is Go and init() function.

Also C++/Java static initialization, C# static constructors, or Rust global variable initialization, ...

Most languages have this feature Afaik

Re: Python 3.15: features that didn't make the headlines

#85

Post by Daishiman »

afH12 wrote: post #29
novov wrote: post #25

Earlier quoted context omitted.

Empirically, I have used the current accepted way to do lazy imports (import statement inside a function) before AI coding was even a mainstream thing, for personal code that sometimes needs a heavy import and sometimes doesn’t. The lazy statement would be an improvement as it allows one to see all the imports at the top where you expect them to be.

As a now deleted comment pointed out, lazy imports had been requested forever. They were rejected forever and were accepted just when BigCorps wanted them . Python-dev now is paid to shore up the failed Instagram stack.

It was accepted just as multiple large corporations with competent teams of internal tool departments ended up forking the interpreter to support lazy imports and demonstrated empirically that the idea has merit.

Re: Python 3.15: features that didn't make the headlines

#86

Post by js2 »

kzrdude wrote: post #78
js2 wrote: post #75

Earlier quoted context omitted.

Type annotations are lazily evaluated by moving them behind a special annotations scope as of 3.14: https://peps.python.org/pep-0649/ https://docs.python.org/3/reference/compound_stmts.html#anno... With 3.15, using lazy typing imports is more or less an alternative to putting such imports behind an "if TYPE_CHECKING" guard.

Ah, thanks for the update. My only check before asking was to check if the future feature for annotations had been enabled by default yet. It has then effectively been abandoned instead, I guess.

Yup, "from __future__ import annotations" will eventually be removed:

> from __future__ import annotations (PEP 563) will continue to exist with its current behavior at least until Python 3.13 reaches its end-of-life. Subsequently, it will be deprecated and eventually removed.

Re: Python 3.15: features that didn't make the headlines

#87

Post by bonesss »

zabzonk wrote: post #35
tyre wrote: post #24

Earlier quoted context omitted.

I felt the opposite, because Python isn’t a great language. It won because of Google, fast prototyping, and its ML interop (e.g. pandas, numpy), but as a language it’s always been subpar. Indentation is a horrible decision (there’s a reason no other language went this way), which led to simple concepts like blocks/lambdas having pretty wild constraints (only one line??) Type decoration has been a welcome addition, bu…

> there’s a reason no other language went this way) Except of course for those that did, Haskell, Fortran for example.

F# as well, and that tends to exist in parallel with some degree of C# written by the same devs… the indentation enables cleaner, smaller, simpler code function by function.

It’s pretty ok in Python, but meaningful indentation is amazing with a proper type system and compiler. Clean, consistent, efficient, and ensures working code is easily read and standardized.

I’m unaware of anyone accepting improperly formatted C# as ‘done’, and would reject any such PR out of hand because of the potential for legibility issues to hide bugs. So: if it were done when 'tis done, then 'twere well it were done by the compiler to save line noise.

Re: Python 3.15: features that didn't make the headlines

#88

Post by WorldMaker »

brookst wrote: post #52
saghm wrote: post #42

Earlier quoted context omitted.

Is the biggest user larger than the combined set of individual users who had asked for (or would benefit from) the same thing? I honestly don't know, but I don't think that things are always as simple as you're implying in a world where we have the collective action problem.

If you’re asking some some kind of abstract moral value sense, I have idea. If you’re asking whether project leads give more weight to a single, tangible, vocal stakeholder than they do to unknown numbers of anonymous and lightly-engaged stakeholders? Yes.

Not to mention when the single, tangible, vocal stakeholder can also be asked to be responsible for documentation (PEPs, etc) and PRs. Especially in open source there is a huge difference between "a lot of people asked about this" and "one person asked about this, but was passionate enough about it and open enough to following the process and the feedback loops to champion it all the way across the finish line".

Re: Python 3.15: features that didn't make the headlines

#89

Post by embedding-shape »

javcasas wrote: post #53
llimllib wrote: post #21

Earlier quoted context omitted.

3.15: https://docs.python.org/3.15/whatsnew/3.15.html#whatsnew315-...

> When an AttributeError on a builtin type has no close match via Levenshtein distance, the error message now checks a static table of common method names from other languages (JavaScript, Java, Ruby, C#) and suggests the Python equivalent Oh, that is such a nice thing.

Now I'm wishing for a single cross-language library, that I can somehow inject into every compiler/runtime/checker to get this, but with a single source of truth and across a wide range of languages. I hit this damn issue all the time, writing code in one language for another, would truly be a bliss to have that problem solved once and for all.

Re: Python 3.15: features that didn't make the headlines

#90

Post by alcazar »

kokada wrote: post #4

From this example: lazy from typing import Iterator def stream_events(...) -> Iterator[str]: while True: yield blocking_get_event(...) events = stream_events(...) for event in events: consume(event) Do we finally have "lazy imports" in Python? I think I missed this change. Is this also something from Python 3.15 or earlier?

This one is really nice. Imports in the middle of a file are very ugly but sometimes necessary. This fixes it in a nicer way.

However, it kind of goes against the principle that “explicit is better than implicit.”

Post reply on HN