491–500 of 558 posts
https://docs.python.org/3.8/whatsnew/3.8.html
I don't know why the downvotes, but I personally much prefer this to the editorialized and incomplete list in the current list. Looking at the module changes, I think my top pick is the changes to the `math` module: > Added new function math.dist() for computing Euclidean distance between two points. > Added new function, math.prod(), as analogous function to sum() that returns the product of a ‘start’ value (default…
>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.
I use it myself all the time, but it just shows the weakness of the tooling that people have to resort to such measures. Fortunately, some people are working on it [1].
>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.
Since print (and hypothetical debug_print) are no longer statements like in 2.x, there's nothing preventing them from returning the string that's supposed to be printed. For example print's keyword file is sys.stdout by default. Why not borrow from Common Lisp's format and make it return the string if file=None is passed? Then you could do logging.warning(debug_print('Unusual situation', foo, bar, file=None)) and it would print "WARNING: Unusual situation: foo=foo_value, bar=bar_value" to the logs. It's so much clearer.
Earlier quoted context omitted.
> and the language got a significant speed boost. I have not seen a clear win in real benchmarks. 3 was slower for the longest time, and nowadays it seems head to head depending on the project.
Check out https://speed.python.org/comparison/ . It’s not significantly faster, but it’s getting more so.
https://speed.python.org/comparison/?exe=12%2BL%2B3.6%2C12%2...
Earlier quoted context omitted.
That's more than I was aware of, but I would hardly call 90% of those "prominent". Sorry to any fans of those languages, but I doubt even most people here on HN have even heard about over half of the languages in that ":=" list.
If someone is not, not a user, but familiar with ALGOL, Simula, Pascal, Modula, Ada, PL/M, Smalltalk, Eiffel, and Oberon, they should not really promote their programming language ideas as relevant... The fact that they use some "new languages" (e.g. whatever derivative stuff happens to be in fashion atm) and are not even aware of the debt of those languages to the list above, doesn't qualify them...
If programming is intellectual onanism for you, then sure you're free to entertain that idea.
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…
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…
users.apply {
asSequence()
filter { it.lastName.startsWith("S")
sortedBy { it.lastName }
take(3)
}
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.
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 acqu…
Earlier quoted context omitted.
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 acqu…
But surely Perl's $_ was way more influential than an obscure PG talk. I was reading PG way back in 2004, and I had never heard of anaphoric macros until now.
Anyway, I'm talking specifically about the use of the identifier "it" in Kotlin, not implicitly or contextually defined identifiers in general, which are indeed a much more widespread concept, embracing Perl's $_ and @_, awk's $0 (and for that matter $1 and $fieldnumber and so on), Dyalog APL's α and ω, Smalltalk's "self", C++'s "this", dynamically-scoped variables in general, and for that matter de Bruijn numbering.
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…
The only frozen languages are the ones nobody uses except for play or academic purposes. As soon as people start using a language, they see ways of improving it. It isn't unlike spoken languages. Go learn Esperanto if you want to learn something that doesn't change.
Earlier quoted context omitted.
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.
>I don't understand why you think print or log debugging is inherently bad. I use it myself all the time, but it just shows the weakness of the tooling that people have to resort to such measures. Fortunately, some people are working on it [1]. >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. Since print (and hypothe…
It's not resorting to anything. It's a valid means of debugging. People use it even in languages like c and Java and in-browser JavaScript with very capable debuggers. It's quick, simple, and doesn't require intervention to record or examine anything.
> Why not borrow from Common Lisp's format and make it return the string if file=None is passed?
Because thatsa terrible idea because it's non-intuitive, verbose, and potentially confusing. Debug format strings are common in other languages, such as rust, so this isn't some half-thoughtout, python-only idea.