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

What's Coming in Python 3.8

lwn.net

Post reply on HN
Print view View original

321–330 of 558 posts

Re: What's Coming in Python 3.8

#321

Post by orf »

Areading314 wrote: post #119
londons_explore wrote: post #70

I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…

Absolutely agree. How many times have you heard "that was true until Python 3.4 but now is no longer an issue" or "that expression is illegal for all Pythons below 3.3", and so on. Not to mention the (ongoing) Python 2->3 debacle.

Who cares about syntax that doesn’t work in old, dead versions of Python 3? 3.5 and above is all that matters.

Re: What's Coming in Python 3.8

#322

Post by zephyrfalcon »

mr_crankypants wrote: post #311
londons_explore wrote: post #70

I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…

Such languages exist. Ones that come to mind offhand are: Standard ML, FORTH, Pascal, Prolog. All of which are ones that I once thought were quite enjoyable to work in, and still think are well worth taking some time to learn. But I submit that the fact that none of them have really stood the test of time is, at the very least, highly suggestive. Perhaps we don't yet know all there is to know about what kinds of prog…

Prolog has an ISO standard... I am not sure if it's still evolving, but specific Prolog implementations can and often do add their own non-standard extensions. For example, SWI-Prolog added dictionaries and a non-standard (but very useful) string type in version 7.

That said, it is nice that I can take a Prolog text from the 1980s or 1990s and find that almost all of the code still works, with minor or no modifications...

Re: What's Coming in Python 3.8

#323

Post by strokirk »

RhodesianHunter wrote: post #293
tachyonbeam wrote: post #180

Earlier quoted context omitted.

I'm 34 and I don't like this, so it's definitely not only those above 35. Jokes aside, I would say I'm a minimalist and this is where my resistance comes from. One of the things that I dislike the most in programming is feature creep. I prefer smaller languages. I like the idea of having a more minimal feature set that doesn't change very much. In a language with less features, you might have to write slightly more c…

> In a language with less features, you might have to write slightly more code, but the code you write will be more readable to everyone else. I disagree with this, which is precisely why I prefer feature rich languages like Java or better yet Kotlin. It doesn't get much more readable than something like: users.asSequence() .filter { it.lastName.startsWith("S") } .sortedBy { it.lastName } .take(3) Now try writing tha…

sorted(u for u in users if u.last_name.startswith("S"), key=lambda u: u.last_name)[:3]

Though I will conceed that I also find the fluent interface variant nicer.

Re: What's Coming in Python 3.8

#324

Post by orf »

sametmax wrote: post #84
coldtea wrote: post #38

Earlier quoted context omitted.

Actually it doesn't violate any of the principles behind the language. It could have been there from day one, like tons of others things added later and now totally loved. I should know, I've worked with Python for 22 years...

Guido disagrees and rejected the idea multiple time in the last 2 decades. I think he worked on Python for a long time too :) This feature is kind of a symbol, the first real decision of the transition between the bdfl and the next era. I'm not worried about it, but yes, it was really against python core principles.

That’s an impressively incorrect history of the operator.

The zen of Python is not a binding constitution. It does not mean nothing can be added if there is some way to do it already, especially if that way improves things. It’s no more “going against the principles” than f-strings where, and they turned out just great.

Re: What's Coming in Python 3.8

#325

Post by ben509 »

sametmax wrote: post #84
coldtea wrote: post #38

Earlier quoted context omitted.

Actually it doesn't violate any of the principles behind the language. It could have been there from day one, like tons of others things added later and now totally loved. I should know, I've worked with Python for 22 years...

Guido disagrees and rejected the idea multiple time in the last 2 decades. I think he worked on Python for a long time too :) This feature is kind of a symbol, the first real decision of the transition between the bdfl and the next era. I'm not worried about it, but yes, it was really against python core principles.

Quoth the PEP[1], Guido changed his mind when he found proof that coders would write redundant (and expensive) code to avoid using a separate line to construct a temporary variable.

So one might argue that a principle of python is that the language is dictated by how people read and write rather than the other way around... it's pretty hard to say what principles are "core" when they all conflict and you have to weigh various tradeoffs.

[1]: https://www.python.org/dev/peps/pep-0572/#the-importance-of-...

Re: What's Coming in Python 3.8

#326

Post by tachyonbeam »

wvenable wrote: post #307
tachyonbeam wrote: post #303

Earlier quoted context omitted.

Yes, and part of the reason they failed is the reason I pointed to: Python is a fast moving target, with an increasing number of features.

It's not the new features of Python that make it hard to optimize; it's the fundamental dynamic nature of the language that was there from day one. Syntactic sugar doesn't have an impact one way or the other on optimizing Python.

The new features aren't just syntactic, they're also new libraries that come standard with CPython, etc. If you want to implement a Python JIT that people will use, you have to match everything CPython supports. Furthermore, since the people behind CPython don't care about JIT, you also can't count on them not adding language features that will break optimizations present in your JIT. You can't count on these being just "syntactic sugar". Even if you could though, in order to keep up it means you have to use CPython's front-end, or constantly implement every syntactic tweak CPython does.

Lastly, AFAIK, CPython's FFI API is actually more of a problem than the dynamic semantics of the language. You can expose Python objects directly to C code. That makes it very hard for a JIT to represent said Python objects in an efficient way internally.

Re: What's Coming in Python 3.8

#327

Post by hermitdev »

mehrdadn wrote: post #94
teddyh wrote: post #24

Earlier quoted context omitted.

“I've come up with a set of rules that describe our reactions to technologies: 1. Anything that is in the world when you’re born is normal and ordinary and is just a natural part of the way the world works. 2. Anything that's invented between when you’re fifteen and thirty-five is new and exciting and revolutionary and you can probably get a career in it. 3. Anything invented after you're thirty-five is against the n…

I don't think it's just >35-year-olds who find what's going on in Python against the natural order of things?

I'm 38, and I'm fine with these changes, and ive been using Python for +15 years.

I can plainly see how these changes will actually make my code cleaner and more obvious while saving me keystrokes.

I also don't think these changes are very drastic. They're opt-in, doesn't break anything and looks to lead to cleaner code. I love the walrus operator (not so sure about the name, but hey. C++ is getting the spaceship operator... As has been said, naming things is hard). To me, the change of print from a statement to a function has been the hardest Python chamge over the years. Just too much mental momentum. Even though ive been on Python 3 for years, I still make the mistake of trying to use it as a statement. That said, I think it was the right (if painful) move.

I don't speak for everyone over 35, just myself.

Re: What's Coming in Python 3.8

#328

Post by mehrdadn »

strokirk wrote: post #323
RhodesianHunter wrote: post #293

Earlier quoted context omitted.

> In a language with less features, you might have to write slightly more code, but the code you write will be more readable to everyone else. I disagree with this, which is precisely why I prefer feature rich languages like Java or better yet Kotlin. It doesn't get much more readable than something like: users.asSequence() .filter { it.lastName.startsWith("S") } .sortedBy { it.lastName } .take(3) Now try writing tha…

sorted(u for u in users if u.last_name.startswith("S"), key=lambda u: u.last_name)[:3] Though I will conceed that I also find the fluent interface variant nicer.

That doesn't parse :-)

Re: What's Coming in Python 3.8

#329

Post by mkl »

owaislone wrote: post #302
mbreese wrote: post #280

Earlier quoted context omitted.

It's not about experience vs inexperience... it's about code readability and being unsurprising. m = re.match(...) if m: ... do something ... is verbose, but quite readable. Given that it's the way things have been done since forever, it's also unsurprising. if m := re.match(...): ... do something ... Without knowing what the walrus operator is, it is not entirely clear what is going on here. := is only syntactic sug…

If feel Go solves this in a much more readable way. if m := re.match(...); m { ... do something ... } Still not as readable as splitting it over multiple lines but quite a lot better than Python's syntax IMO especially once you learn how the if statement works in Go.

How is that more readable? It's identical except for ":" -> ";", and some extra symbols added. Needing to repeat "m" seems seems redundant, and particularly bad for readability as it moves the actual condition far away from the "if".
Post reply on HN