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

481–490 of 558 posts

Re: What's Coming in Python 3.8

#481

Post by kragen »

riffraff wrote: post #363
kragen wrote: post #337

Earlier quoted context omitted.

Yeah, a bit of PG’s Arc influence in the wild.

I believe groovy made this popular rather than arc, and it's likely where kotlin's come from, due to being in the java ecosystem.

Groovy is from 2003. PG keynoted PyCon in 2003 talking about his progress on Arc: http://www.paulgraham.com/hundred.html. He had been talking about Arc online for a couple of years at that point, including in particular the convenience of "anaphoric macros" that defined the identifier "it" as an implicit argument.

(He'd also written about that more at length in the 1990s in On Lisp, but many more people became acquainted with his language-design ideas in the 2001–2003 period, thanks to Lightweight Languages and his increasingly popular series of essays.)

Re: What's Coming in Python 3.8

#482

Post by kragen »

jnordwick wrote: post #386
riffraff wrote: post #363

Earlier quoted context omitted.

I believe groovy made this popular rather than arc, and it's likely where kotlin's come from, due to being in the java ecosystem.

Most apl deviatives (j, k, q, a) all had implicit arguments for functions that didn't explicitly declare them (up to 3: x, y, and z). Probably before then too.

Dyalog APL too, but none of them call the implicit argument "it".

Re: What's Coming in Python 3.8

#483

Post by kragen »

elcritch wrote: post #377
kragen wrote: post #336

Earlier quoted context omitted.

Python is a little more readable, but both Python and Kotlin are perfectly clear in this case: sorted((u for u in users if u.last_name.startswith("S")), key=lambda u: u.last_name )[:3] If last_name is a function, which it often would be in Python, it gets better: sorted((u for u in users if last_name(u).startswith("S")), key=last_name )[:3] However, I think you probably got the sort key wrong if you're taking the fir…

I disagree this python version is as readable and here’s why. It’s about as many characters but more complex. The Kotlin version performs several distinct actions, each being clear to its purpose. These actions have the same syntax (eg requires less parsing effort). The Python version mixes at least 4 different language syntax/features, being list comprehension, if special form in the list comprehension, keywords, an…

It's surprising to me that there are people who disagree with my opinion about this, but it suggests that my familiarity with Python has damaged my perspective. You're clearly much less familiar with Python (this code doesn't contain any list comprehensions, for example), so I think your opinion about readability is probably a lot more objective than mine.

Re: What's Coming in Python 3.8

#485

Post by brummm »

kbd wrote: post #118

Despite controversy, walrus operator is going to be like f-strings. Before: "Why do we need another way to..." After: "Hey this is great". People are wtf-ing a bit about the positional-only parameters, but I view that as just a consistency change. It's a way to write in pure Python something that was previously only possible to say using the C api.

I think in certain situations the walrus operator will probably be useful. But it definitely makes code less legible, which makes me cautious. The only useful use case I have found so far is list comprehensions where some function evaluation could be reduced to only one execution with the walrus operator.

Re: What's Coming in Python 3.8

#486

Post by heavenlyblue »

hjk05 wrote: post #463
heavenlyblue wrote: post #459

Earlier quoted context omitted.

Nothing stops one from evaluating f-strings lazily. They could simply return a format string with parameters captured instead of interpolated string.

They could... but then they wouldn’t return the interpolated string, and they’d be just like using format, just saving the characters “.format” which ruins the exact thing people like about them.

Nah - you're clearly not using Python enough - the issue with current format is that of the identity of the arguments passed to it.

I need to do 2 changes every time I change a format string - I need to remove the symbol representing it's placement and then I need to remove the argument passed to .format.

Also old formatting does not easily support arbitrary expressions in the placements, thus in order to get those you need to change the arguments passed to the .format.

f-strings get rid of those issues altogether. What you're showing is whatever you have in the brackets - 0 indirection and thus less margin for (unnecessary) errors.

Re: What's Coming in Python 3.8

#487

Post by Grue3 »

>Python 3.8 programmers will be able to do: print(f'{foo=} {bar=}')

Ugh, how did this get approved? It's such a bizarre use case, and debugging by print should be discouraged anyway. Why not something like debug_print(foo, bar) instead (because foo and bar are real variables, not strings)?

Re: What's Coming in Python 3.8

#488

Post by jimktrains2 »

Grue3 wrote: post #487

>Python 3.8 programmers will be able to do: print(f'{foo=} {bar=}') Ugh, how did this get approved? It's such a bizarre use case, and debugging by print should be discouraged anyway. Why not something like debug_print(foo, bar) instead (because foo and bar are real variables, not strings)?

I don't understand why you think print or log debugging is inherently bad.

Also, it's part of the format string and not a special print function so that it can be used for logs and other output as well, not just the console.

Re: What's Coming in Python 3.8

#489

Post by aportnoy »

solarist wrote: post #422
aportnoy wrote: post #404

Earlier quoted context omitted.

I’ve been waiting for this for a very long time. Thank you for mentioning this. Would this work with e.g. large NumPy arrays? (and this is Raymond Hettinger himself, wow)

An alternative you may want is Dask.

Dask doesn’t support shared memory without pickling because Python doesn’t.

Re: What's Coming in Python 3.8

#490

Post by Razengan »

masklinn wrote: post #446
riffraff wrote: post #365

Earlier quoted context omitted.

I also cannot honestly think of a case where I want that behaviour. The "pow" example looks more like a case where the C side should be fixed.

> I also cannot honestly think of a case where I want that behaviour. There's plenty of situations where a named argument does not help, and encoding it can only hurt. It makes little to no sense to name the first argument to `dict.update` for instance. Or the argument to `ord`. That, incidentally, is why Swift added support for positional-only parameters (though it has no concept of keyword-or-positional).

> That, incidentally, is why Swift added support for positional-only parameters (though it has no concept of keyword-or-positional).

Swift's syntax is a lot more intuitive and consistent:

    function(parameterWithImplicitlyRequiredLabel: Int,
             differentArgumentLabel internalParameterName: Int,
             _ parameterWithoutLabel: Int, 
             variadicParameterWithLabel: Int...)
which you would call as

    function(parameterWithImplicitlyRequiredLabel: 1, differentArgumentLabel: 2, 3, variadicParameterWithLabel: 4, 5, 6, 7)
[0] https://docs.swift.org/swift-book/LanguageGuide/Functions.ht...
Post reply on HN