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

311–320 of 558 posts

Re: What's Coming in Python 3.8

#311

Post by mr_crankypants »

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 programming language constructs provide the best tooling for writing clean, readable, maintainable code, and languages that want to try and remain relevant will have to change with the times. Even Fortran gets an update every 5-10 years.

I also submit that, when you've got a multi-statement idiom that happens just all the time, there is value in pushing it into the language. That can actually be a bulwark against TMTOWTDI, because you've taken an idiom that everyone wants to put their own special spin on, or that they can occasionally goof up on, and turned it into something that the compiler can help you with. Java's try-with-resources is a great example of this, as are C#'s auto-properties. Both took a big swath of common bugs and virtually eliminated them from the codebases of people who were willing to adopt a new feature.

Re: What's Coming in Python 3.8

#312

Post by orf »

marmada wrote: post #241
simondw wrote: post #62

Earlier quoted context omitted.

But now there are two ways to do assignment. That's not very pythonic, is it?

I never felt like there was only one way to do something in Python. Every Stack Overflow question has a multitude of answers ranging from imperative to functional style and with various benefits and drawbacks. Python is one of the least "only one way to do things" languages I've used. This even extends to its packaging system, where you can choose between virtualenv, pipenv, pyenv, etc. Same goes for the installation…

Packaging isn’t really anything to do with the language syntax, or the zen of Python. Any critiques on Python-the-language?

And pyenv is just a version manager, like rbenv or nvm. I wouldn’t consider its existence confusing, not would I say being able to install something in more than 1 way has any relevance to the zen of Python!

Should Python create some cross-platform Uber-installer so that there is only one download link?

Re: What's Coming in Python 3.8

#313

Post by zephyrfalcon »

ben509 wrote: post #292
theplague42 wrote: post #77

Earlier quoted context omitted.

Assignment can be confusing already. >>> locals()['a'] = 1 >>> a 1 If anything, the walrus operator allows for tightly-scoped assignment, which is good in my opinion.

You don't even need the locals() function to get into trouble: x = [1, 2, 3, 4] def foo(): x[0] += 3 # Okay def bar(): x += [3] # UnboundLocalError def qux(): x = [5, 6, 7, 8] # Binds a new `x`.

    def bar():
        x += [3]   # UnboundLocalError
This is an especially funky one. x.extend([3]) would be allowed. Presumably x += [3] is not because it expands to x = x + [3]... However, the += operator on lists works the same as extend(), i.e. it changes the list in-place.

Re: What's Coming in Python 3.8

#314

Post by orf »

newen wrote: post #281
tomkat0789 wrote: post #230

Earlier quoted context omitted.

What's stopping people from forking the language at python 2.7? Let the pythonistas add whatever feature they feel like while people who need stability use "Fortran python" or whatever.

I truly wish this would become a thing. It's really frustrating having to update my installed packages and my code for some stupid change the language designers thought is sooo worth it. Just stabilize the bloody thing so I can do some work. Updating code so it meshes with the "latest and greatest" is _not real work_.

Fixing the entirely broken string/bytes mess up in Python 2 was worth it by itself. For bonus points old style classes went away, and the language got a significant speed boost. And now it’s not going to die a slow death, choking on the past poor decisions it’s burdened with.

Trivializing that by suggesting it was some offhand, unneeded solution to a problem that some dreamy “language designer” thought up is at best completely and utterly ignorant.

Also maintenance, in all forms, is work. That does involve updating your systems from time to time.

Re: What's Coming in Python 3.8

#315

Post by mr_crankypants »

knome wrote: post #271
stakhanov wrote: post #56

Earlier quoted context omitted.

It's wrong to frame this as resistance to change for no reason. See my other comment. I see some of this stuff as repeating mistakes that were made in the design of Perl. ...but there are quite few people around these days who know Perl well enough to recognize the way in which history is repeating itself, and that has at least something to do with age.

"resistance-to-change for-no-reason" vs "resistance-to change-for-no-reason" :)

Both of which, it's worth noting, are painfully obvious and uncharitable strawmen.

Re: What's Coming in Python 3.8

#316

Post by hermitdev »

fny wrote: post #224
heydenberk wrote: post #172

Earlier quoted context omitted.

I'd used f-string-like syntaxes in other languages before they came to Python. It was immediately obvious to me what the benefit would be. I've used assignment expressions in other languages too! Python's version doesn't suffer from the JavaScript problem whereby equality and assignment are just a typo apart in, eg., the condition of your while loop. Nonetheless, I find that it ranges from marginally beneficial to ma…

I love string interpolation! But this seems to take it to a bizarre level place just to save a few keystrokes. Seriously, how is f"{now=!s}" substantially better than f"now={str(now)}"? Ergonomically, I see little benefit for the added complexity.

I agree that the simple examples don't show much benefit, but imagine if you had a really complex expression. I can see the value there.

Re: What's Coming in Python 3.8

#317

Post by Stubb »

vesche wrote: post #101

Was really hoping to see multi-core in 3.8, looks like we'll be waiting until 3.9 https://www.python.org/dev/peps/pep-0554/ https://github.com/ericsnowcurrently/multi-core-python/wiki

A map() function that isn't just an iterated fork() would be glorious. Let me launch a thread team like in OpenMP to tackle map() calls containing SciPy routines and I'll be unreasonably happy.

Re: What's Coming in Python 3.8

#318

Post by stefco_ »

bpchaps wrote: post #308
stefco_ wrote: post #215

Earlier quoted context omitted.

Yes! `textwrap.dedent` is great. On further reflection `wrap` is actually more useful for this kludge (see below). But my point is that that's a whole import for a kludge. Compare the f-string ideal (by my standards): raise ValueError("File exists, not uploading: " f"{filename} -> {bucket}, {key}") ...which is short enough that it's readable, and it's clear where exactly each variable is going. It's the single obviou…

Here's a clean way to do that: str_fmt = "File exists, not uploading: {filename} -> {bucket}, {key}" fmt_vals = dict(filename=filename, bucket=bucket, key=key) raise ValueError(str_fmt.dedent().format(**fmt_vals))

This is somewhat cleaner, and I also use this idiom when things get ugly with the inline formatting shown above. But my point is that none of these are very elegant for an extremely common use case. Throw this block in the middle of some complex code with a few try/except and raise statements and it still looks confusing. Having two extra temp variables and statements per error in a function that's just doing control flow and wrapping unsafe code can double your local variable count and number of statements across the whole function. AFAIK, there has been no elegant solution to this common problem until f-strings came around; the only decently clean one is using printf-style format strings with the old-style operator, but outside of terseness I find it less readable.

Re: What's Coming in Python 3.8

#319

Post by mehrdadn »

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…

A little off-topic but how does that work? Is 'it' a magic variable referring to the first argument? Never seen magic variables that blend into lambdas like that before... would've expected $1 or something like that.

Re: What's Coming in Python 3.8

#320

Post by mkl »

toxik wrote: post #278
nerdponx wrote: post #207

Earlier quoted context omitted.

I envisioned it like "if/else" or "for/else" or "while/else", where a "do" block must be followed by a "while" block. x = 0 do: x += 1 while: x

This completely contradicts the rest of Python grammar, and indeed many languages’ grammars. The consistent way would then be `while x < 10` but that too looks ridiculous. The issue is that you can’t have post-clause syntax in Python due to its infamous spacing-is-syntax idea.

Of course you can have post-clause syntax: if...else, try...except, for...else, etc.

(Edit: Actually, I think I know what you were saying now, and those aren't quite the same thing as they need a line after them.)

I do think the condition on the next line isn't the way to do solve this problem though (and I don't think it needs solving, while True: ... if ...: break does the job).

Post reply on HN