401–410 of 558 posts
Earlier quoted context omitted.
I don't know how you read it - 'if x is assigned the value y'? Most other things in Python can just be read out loud.
> I don't know how you read it “... x := foo ...” is read “... x, which is foo, ...”
Some kinds of data can be passed back and forth between processes with near zero overhead (no pickling, sockets, or unpickling).
This significantly improves Python's story for taking advantage of multiple cores.
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.
Me, I am old enough to know Perl, and I've got plenty of one-line skeletons in my own closet. And it more-or-less entered the world already vastly more TMTOWTDI-y than Python is after 3 decades. FWIW, I tend to think of comparisons to Perl as being a lot like Nazi comparisons, only for programming languages. And I do think there's some wisdom to the Godwin's Law idea that the first person to make a Nazi comparison is…
To me, the headline feature for Python 3.8 is shared memory for multiprocessing (contributed by Davin Potts). Some kinds of data can be passed back and forth between processes with near zero overhead (no pickling, sockets, or unpickling). This significantly improves Python's story for taking advantage of multiple cores.
Would this work with e.g. large NumPy arrays?
(and this is Raymond Hettinger himself, wow)
Python looks more and more foreign with each release. I'm not sure what happened after 3.3 but it seems like the whole philosophy of "pythonic", emphasizing simplicity, readability and "only one straightforward way to do it" is rapidly disappearing.
I do agree that Python is moving further and further away from the only-one-way-to-do-it ethos, but on the other hand, Python has always emphasized practicality over principles.
Earlier quoted context omitted.
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 weig…
Earlier quoted context omitted.
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.
See other replies. Guido was for the operator.
Earlier quoted context omitted.
My metric for this is to put some of my freshest student in front of a code and see how they deal with it. How easily can they understand it ? How easily can they write it ? Debug it ? They are most of the time a fantastic indicator of the cognitive load a feature will add in prod. Because of course a feature doesn't exist in a vacuum, it's always in a more complex context. So what's easy to understand for a student…
> my freshest student in front of a code and see how they deal with it. That is fine if you want to optimize language for "fresh students". That is not representative how brain process stuff after getting even some experience.
Earlier quoted context omitted.
Furthermore, I did my grad studies in compilers. I've thought about writing an optimizing JIT for Python. I really feel like CPython is needlessly slow, and it's kind of embarassing, Many have tried and failed, Google and Dropbox to name a couple, and countless other attempts.
It lags a bit in releases, but I understood pypy to be essentially successful?
Earlier quoted context omitted.
F-strings have appeared 2 versions ago. All in all, the feedback we have has been overwhelmingly positive, including on maintenance and readability.
F-string are great and should have been in the language since the beginning. Many other languages had with their own version of them since version 0. What I don't understand is why Python needs a special string type when other languages can interpolate normal strings (Ruby, Elixir, JavaScript.)