Live data from Hacker News

Python 3.15: features that didn't make the headlines

blog.changs.co.uk

191–200 of 236 posts

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

#191

Earlier quoted context omitted.

function Greeting({ name }: { name: string }) { return ( Hello, {name}! Welcome to my site. ); } That looks like HTML, but it's TypeScript. It gets compiled to actual HTML. Can any Python framework do that?? In Python, you'd typically write your logic in Python and your HTML in a separate Jinja2 template file — two languages, two files, context-switching. With Fresh + TSX, your logic and your markup live together in…

That's the ugliest spaghetti i've seen in a long time. Why would anybody want to do that to themselves or their co-coders? Yes, separating html out in jinja2 or whatever is far superior.

It's poorly formatted here of course. In reality it's better. As for why:

1. You can compose HTML using normal code - functions, loops, etc. No separate shitty template language or whatever.

2. You get full support for static typing and IDE code intelligence. That's huge and pretty much unique to TSX.

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

#192
post #189

I used to be obsessed about language design and now, since I almost never write code directly (it's always Claude), I completely lost interest. It feels like a total waste of time and I wonder if other feel the same. One of the consequences of the LLM tsunami might be the freezing of research and development in programming languages. Maybe we'll be stuck with J's and python forever...

> I almost never write code directly (it's always Claude)

Who, then, understands the code? If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code, and for that the knowledge of language is still relevant.

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

#194
post #192
post #189

I used to be obsessed about language design and now, since I almost never write code directly (it's always Claude), I completely lost interest. It feels like a total waste of time and I wonder if other feel the same. One of the consequences of the LLM tsunami might be the freezing of research and development in programming languages. Maybe we'll be stuck with J's and python forever...

> I almost never write code directly (it's always Claude) Who, then, understands the code? If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code, and for that the knowledge of language is still relevant.

> If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code

I think about this on the regular -- I know the answer is currently "you own the code, so you have to understand it", but to unlock the true productivity multiplier, in the future, the answer has to be "no one really".

I think about it using the concepts from my job (academia) -- to actually have PhD student-level intelligence means that you have to trust that it does a good enough job that you can focus on other stuff. Professors often bring the correct ideas or intuitions, but they have to trust the PhD student to write the code and/or fill in the gaps in the proofs -- they can advise them on the high-level issues during a consultation, but that's about it.

I am pretty bad at working in the current LLM workflow -- it is tough for me to focus on reading a TCS paper for review, keeping all the details and invariants in my head, but every 5-10 minutes go to my PC, completely switch contexts/projects, read the code and think about the LLM's comments, suggest the next step, and then go back to reading.

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

#195

Earlier quoted context omitted.

Typescript wins in terms of training data IMHO, by which I mean that the training data is large enough that AI does great with TS, and the language is (IMHO) superior to Python in many ways. I personally now use a mixture of Typescript and Rust for most things, including AI coding. Its been working quite well. (AI doesn't handle Rust as well as TS, in that the code isn't quite idiomatic, but it does ok)

Upvoted you, because the downvotes from the Python cult are unfair.

Haha thanks. Funny thing is, I’ve been a long time Python fan, learning it in 2001 and using it extensively for a long time. But then I learned Clojure, Typescript, and recently Rust and I’ve found Python to be quite flawed. But it sure does have a cult following.

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

#196
post #59

I was so into Python for 10 years, was enjoyable to work in. But have deleted 100k+ lines this year already moving them to faster languages in a post AI codebot world. Mostly moving to go these days.

I'm still on the lookout for a comprehensive Django-like web framework for go. That would be an instant hit for me.

Or just use Django. You can later identify hot spots and bottlenecks and spin out Go services where applicable.

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

#198
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?

Note that you can work around it by implementing `def __getattr__(name: str) -> object:` at the module level on earlier Python versions

Opus 4.7 did this in my code and I had never seen it before

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

#199
post #82

Earlier quoted context omitted.

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? M…

> potentially slower execution in return for faster development time, for example. Another classic lie about Python. The slower speed doesn't matter because it's development speed that's important, and Python gives you faster development speed! Except... it absolutely doesn't. It would be very difficult to argue that Typescript has significantly slower development speed but it is much faster to execute. I also disagr…

The case I would make is that some of the libraries in Python are very fast and written in other languages (C, C++, etc...). With other languages that's more rare. For instance a Java application will probably use libraries that are all Java (or another JVM language).

The gotchas that I see with Python are that some really garbage code can work - that's more difficult in a language like Rust. The other nice thing about Python (aside from the fact that it can be very readable) is that devs rarely use threads and threads cause all sorts of race conditions - often when the performance of threading was never needed in the first place and the usage of them just added pointless complexity.

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

#200

One of the Counter examples is incorrect, tested on both 3.13 and 3.15.0a >>> from collections import Counter >>> c = Counter(a=3, b=1) >>> d = Counter(a=1, b=2) >>> c-d Counter({'a': 2})

I noticed that as well. Per the docs:

  Several mathematical operations are provided for combining Counter objects to produce multisets (counters that have counts greater than zero). Addition and subtraction combine counters by adding or subtracting the counts of corresponding elements. Intersection and union return the minimum and maximum of corresponding counts. Equality and inclusion compare corresponding counts. Each operation can accept inputs with signed counts, but the output will exclude results with counts of zero or less.
Anyway, nice Counter-example ;-)
Post reply on HN