421–430 of 558 posts
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.
But still copying?
If not, then how does it interoperate with garbage collection?
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.
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)
Earlier quoted context omitted.
Does that mean someone born in 2008 will think C++ is simple and elegant?
I am both a Python programmer and a C++ programmer. I have programmed professionally full time in one or the other for years at a time. I think C++ is now a much better language than when I learnt it first (cfront). In particular C++11 really fixed a lot of the memory issues with shared_ptr and std:: algorithms. It is a better language now if you are doing anything larger than then a program that takes more than a fe…
I stopped writing C++ at some point in 2008/2009 but I still keep track of it to some extent and I'm continually surprised by the nonsense that is introduced into the language. The whole RAII movement, for example, is just one massive band-aid on top of the previous mistake of allowing exceptions, etc..
It'd be mostly fine in the long run, but you have all these people using like 15% of C++ and complain about it all day long, making their libraries not usable from stuff that understands C (most of which have drastically improved on the whole paradigm). There's a solution here and it's not using whichever arbitrary percentage you've decided on of C++, it's realizing that there are way better languages with real interoperability in mind to talk about lower-level things.
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.
Earlier quoted context omitted.
But now there are two ways to do assignment. That's not very pythonic, is it?
I see this criticism every time the walrus operator is brought up. You do know that this: x := 1 Is going to be a syntax error, right? The walrus operator is not permitted in the case of a simple assignment statement. It's only in an expression.
When is an expression allowed to have := in it, is
(x := 1)
Earlier quoted context omitted.
By itself I agree, every now and then you write a few lines that will be made a little shorter now that := exists. But there's a long standing trend of adding more and more of these small features to what was quite a clean and small language. It's becoming more complicated, backwards compatibility suffers, the likelyhood your coworker uses some construct that you never use increases, there is more to know about Pytho…
they should pick f and put depreciation warnings on the other two, python is getting messy.
That walrus operator has given me exactly what I wanted from C. Although I'd have preferred: if val = expr():
That particular version opens the way for massive typo footguns and results in the insanity of defensive programming patterns like yoda expressions.
Most likely, the assigned value is stored for use in one of the conditionals, so it really doesn't change any of that.
Let's also understand that we are dealing with a decorated assignment here, so a = (b = c) should be no different from evaluating (b = c). It's not complicated, the way I at least look at it.
Earlier quoted context omitted.
One of the good things about not using the "=" operator is that you cannot accidentally turn a comparison into an assignment, a feature that is a common cause of errors in other languages that do support it. By adding a completely different character to the operator it is not very likely to cause bugs, compared to just forgetting to type that second =
Is it really that common? I made this typo a few times in my life. It was corrected every time before the program actually run because the compiler warned me about it. I don't see how you can make this mistake if you're not aggressively trying (by turning off warnings for example).
Earlier quoted context omitted.
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…