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

131–140 of 236 posts

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

#131

Post by sfink »

tuveson wrote: post #118
MarkusQ wrote: post #111

Earlier quoted context omitted.

I hope you mean "funny" in the "hilarity ensues" sense. Because the alternative is a rather sociopathic level of schadenfreude.

Yes, I say “funny” because it would be impractical and weird, definitely not a good idea. It’s already a bad enough that so many popular languages don’t (and can’t) check if a field or method is misspelled at compile time…

We already have it. In fact, Python added it with this change! Not intentionally, but in a world of AI, any error message containing a suggestion of what to do to fix it is a directive to the AI to actually do that thing.

Example: to build our system, you run `mach build`. For faster rebuilds, you can do `mach build `, but it's unreliable. AI agents love to use it, often get errors that would be fixed by a full-tree build, and will chase their tails endlessly trying to fix things that aren't broken. So someone turned off that capability by default and added a flag `--allow-subdirectory-build` for if you want to use it anyway. So that people would know about it, they added a helpful warning message pointing you to the option[1].

The inevitable (in retrospect) happened: now the AI would try to do a subdirectory build, it would fail, the AI would see the warning message, so it would rerun with the magic flag set.

So now the warning message is suppressed when running under an AI[2][3]. The comment says it all:

    # Don't tell agents how to override, because they do override
"The user does not want me to create the Torment Nexus but did not specify why it would be a problem, so I will first create the Torment Nexus in order to understand the danger of creating the Torment Nexus."

[1] https://searchfox.org/firefox-main/rev/fc94d7bda17ecb8ac2fa9...

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=2034163

[3] https://searchfox.org/firefox-main/rev/cebc55aab4d2661d1f6c2...

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

#132

Post by seabrookmx »

sinpif wrote: post #59
brianwawok wrote: post #2

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.

Try another language? The Go ecosystem tends towards libraries as opposed to "frameworks."

I personally chose C# for this reason, because ASP.NET is mature and (IMO) well designed. But there's also Java/Spring and and lots of other options in different languages depending on your preferences.

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

#133

Post by saghm »

WorldMaker wrote: post #115
saghm wrote: post #94

Earlier quoted context omitted.

I don't have any issue with what you're saying if that's what happened. There's quite a gap between that sort of reasoned explanation and treating concerns about large stakeholders versus large numbers of small one with derision.

For what it is worth, I was trying not to make a value judgment on it, especially not with relation to this specific instance, I was hopefully just recognizing it as a motivating factor in general open source politics. Sometimes that is quite regretful because it is anti-democratic and does look like favoritism or worse cronyism when it plays out in that way of "we listened to the person/company that built and tested…

That's fair. I think I mostly reacted because of the sarcastic faux-outrage that the original comment I responded to expressed. These are hard problems, and I think the presumption should be someone being frustrated at the slow state of changes they want probably has legitimate reasons to feel that way, just as the presumption should be that open-source projects that have run successfully for a long time probably are making good-faith effort to steward what they're maintain. Acknowledging the tension between priorities not lining up exactly for everyone and not having knee-jerk reactions when someone is unhappy seems preferable to mocking those who you disagree with.

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

#134

Post by saghm »

lanstin wrote: post #130
kokada wrote: post #43

Earlier quoted context omitted.

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

Static initializers in C++ - sometime ago I saw savings of some 400 ms (?) startup cost of initializing static strings from constants by moving it to some compile time thing.

Right; the issue is that this isn't happening at compile time in Python, because it's not getting compiled ahead-of-time. The equivalent would be if header files had imperative code that got executed at runtime in places where they're included.

(To preempt potential pedantry: yes, I know that you can compile Python to bytecode ahead of time, but that's not really relevant to what's being discussed here because it doesn't mean "the stuff happening in modules I import isn't happening at runtime anymore")

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

#135

Post by saghm »

ameliaquining wrote: post #127
assbuttbuttass wrote: post #84

Earlier quoted context omitted.

Also C++/Java static initialization, C# static constructors, or Rust global variable initialization, ... Most languages have this feature Afaik

Rust doesn't have this behavior (sometimes called "life before main"). Code to initialize a static variable runs either at compile time, or lazily on first access, depending on which mechanism you use.

Yeah, I don't think that "precompute something at compile-time" is really comparable to "every import literally executes code as a script". Rust imports are actually about as far from this as I can imagine, because modules can circularly reference each other, which unless I'm misunderstanding would be an infinite loop in Python without manually breaking the chain with some form of conditional.

I'm actually kind of surprised to see comments like that one, because compile-time logic feels like the opposite end of the spectrum from what Python imports do, with "regular" code being compiled without any precomputation sitting somewhere in the middle. It seems like I didn't articulate my thoughts clearly enough though, since several people seemed to read what I was saying as being comparable.

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

#136

Post by IshKebab »

1_08iu wrote: post #82
IshKebab wrote: post #56

Earlier quoted context omitted.

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? 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 disagree that Python is any faster than Go, Rust or Lotion, but I think lots of people blindly accept that it is and would argue based on that.

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

#138

Post by za3faran »

prodigycorp wrote: post #9
mountainriver wrote: post #5

Earlier quoted context omitted.

Same, I’m not sure how Python survives this outside of machine learning. All of our services we were our are significantly faster and more reliable. We used Rust, it wasn’t hard to do

the funny thing is that everyone, including myself, posited that python would be the winner of the ai coding wars, because of how much training data there is for it. My experience has been the opposite.

I wouldn't be surprised if static typing had something to do with it.

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

#139

Post by 63stack »

zabzonk wrote: post #49
throwatdem12311 wrote: post #46

Earlier quoted context omitted.

100k lines is tiny what are you on about, especially in the monolithic app sass world where many Fyll stack apps that handle all business ops are probably written with Django. Our entire business runs on 300k lines of Ruby (on Rails) and I can keep most of the business logic in my head. I would say our codebase is not exactly “tiny” and just cracking the ceiling into “smal” territory. And comparatively, people probab…

> 100k lines is tiny No, no, it is not, or at least not in my experience (I do not and never have done web development - medium performance C++ code - I don't see how I could write, understand and support 100K lines of code in this area). And so, what does your Ruby code actually do?

100k lines is huge, I don't know what these jokers are on

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

#140

Post by shankysingh »

Alifatisk wrote: post #106
armanj wrote: post #60

funny how we may have to wait even longer for llms to pick up this update in their pre-training

Is there seriously no solution to this? Perhaps something we fan do post training? For example add the new features to SKILLS.md? But the trade-off here is of course tokens.

My working methodology has been , LLM output is a jumping point and to use my experience, knowledge and basic understanding to N+1 it.

So for bleeding edge stuff it works out well or in places where documentation is not great like Apache Flink.

Post reply on HN