Hacker News Reader

Comment by zarzavat | Hacker News Reader

I feel like there’s a clash of cultures.

There’s Python the scripting language, replacement for bash scripts, R and Lua.

Then there’s Python the serious software development language. Where people have style guides, code review, test coverage, and projects with more than one directory.

I understand why people in the second group are fearful of this feature and DSLs in general. I’m in the first group and I’m quite excited for it.

View on HN

I'm in both groups and I'm getting tired of how Python's syntax additions increasingly turn it into a mechanism for mid-level engineers to assert their dominance over colleagues by writing code that only people who have been deeply immersed in Python for years can understand.

Our Python users' Slack channel at work is already overcrowded with messages to the effect of, "halp what's this syntax how does this code work."

A perfect use case for chatbots to answer them instead.

This is a problem with our industry that people get paid $$$ to use a language but at no point are they compelled to read the manual for that language from cover to cover.

For real. How long does it realistically take to stay informed of the language's evolution? Literally a few hours every couple months, not much more.

Hi, I'm a PEP author. The hope was that users would say "I know f-string syntax so I know this syntax." Similar to JS and its template literals -> tagged template literal jump.

That would be an easy mental jump for skilled python users, but I think that it would be surprising for many less experienced users. Just giving it a function call syntax would be more in line with the principles established in PEP-20 IMO.

If I understand correctly, you'd prefer what other commenters have said for `html(i"Hello {name}")`?

Something like that, yeah.

I'm in the second group and I'm very excited for it, getting the linting right to prevent people doing wild formatting into dangerous string-based APIs is not easy, this provides an opportunity to make it much easier and safer.

And the second group is already likely to have a linter set up. The author's fears about this showing up in library code is still valid though

I can get behind that. I see some of the same issue in regards to type annotation. I'm heavily leaning into the dynamic / duck-typing aspects of Python, so type annotation is often complicated or very broad, to the point where it's a little redundant. If you're not really writing code like that, type annotation is an awesome addition to the language.

I'd be very interested in seeing where this goes, it certainly has it's uses, but there's also a ton of projects where it really doesn't belong.

I'd be interested in chatting with you sometime on duck typing (protocols) and how it (along with this PEP) could bring component-driven development to Python.

Python is too big to be a proper Lua replacement.

It was a reference to PyTorch, admittedly somewhat oblique.

Python is very popular for machine learning, in days gone past ML researchers used the Torch library in Lua. TensorFlow and PyTorch made Python the dominant language in that field.

https://en.wikipedia.org/wiki/PyTorch

Reply on news.ycombinator.com