521–530 of 558 posts
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.
Earlier quoted context omitted.
But it used to be that any expression on its own was a valid statement. Is that going to change? When is an expression allowed to have := in it, is (x := 1) on its own allowed?
Allowed, yes. But the PEP that introduced walrus operators says not to do it. Every possible line of code has an alternate ugly way to write it. This isn't a valid criticism. Anyone who decides to start writing simple assignment statements like that deserves to be ridiculed for writing ugly code.
I just dislike that the simple syntax rule "any expression can be used as a statement" now has an exception.
I haven't been able to think of scenarios where that might have consequences (code generation or refactoring tools?) but that doesn't say much as I'm not that smart.
Edit: having looked at the cases that are disallowed, they remind me of generator expressions. Those are usually written with parens, that can optionally be omitted in some cases. := is the same except they can be omitted in so many cases that it's easier to list the cases where they can't.
I think a generator expression used as a statement already requires the parens, even though they can be omitted e.g. as a single parameter of a function call. So that's probably ok then.
Earlier quoted context omitted.
I'm not sure why the consistent way looks ridiculous. do: body() body() while x It's just a compound statement consumes the trailing while clause. Decorators already precede a function (or class) definition[2], and one alternative for the ill-fated switch statement[1] was to have switch precede the case blocks to avoid excessive indentation. So there's plenty of precedent in the other direction. [1]: https://www.pyth…
I think you're really stretching it when you say "there's plenty of precedent," arguably there is none as the decorator syntax is pre-clause and thus poses no indentation reading issues. So too for the proposed switch statement syntax. Then there is the fact that the decorator syntax is perhaps the most alien of all Python syntax, sometimes criticized for being Perlesque, perish the thought (on account of it being in…
> What if the while statement was part of the loop and could be placed arbitrarily?
If you're open to that, I had thought this was a bridge too far, but:
do:
body1()
break if some_condition
body2()
continue if some_other_condition
while True:
do_body
break
Earlier quoted context omitted.
In my experience, every technology focused on building a "simple" alternative to a long-established "complex" technology is doomed to discover exactly _why_ the other one became "complex." Also spawn at least five "simple" alternatives. Doesn't mean nothing good comes out of them, and if it's simplicity that motivates people then eh, I'll take it, but gosh darn the cycle is a bit grating by now.
Could you provide some examples? Without having had that experience, I’m having trouble picturing a concrete example that I would be sure is of the same kind.
Projects like qmail discovered the reason in a somewhat _harder_ manner. And yes, I'd argue Python is yet another case, as it grew _at least_ as complex as Perl.
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.
It looks like this will make efficient data transfer much more convenient, but it's worth noting this had always been possible with some manual effort. Python has had `mmap` support at least as long ago as Python 2.7, which works fine for zero-overhead transfer of data. With mmap you have to specify a file name (actually a file number), but so long as you set the length to zero before you close it there's no reason a…
Earlier quoted context omitted.
Can you give an example of something like this happening to the language? IMO 3.6+ brought many positive additions to the language, which I also think are needed as its audience grows and its use cases expand accordingly. The walrus operator makes while loops easier to read, write and reason about. Type annotations were a necessary and IMO delightful addition to the language as people started writing bigger productio…
> F strings are %-based interpolation done right, and the sooner the latter are relegated to "backward compatibility only" status the better. They are also more visually consistent with format strings. No, f-strings handle a subset of %-based interpolation. They're nice and convenient but e.g. completely unusable for translatable resources (so is str.format incidentally).
F strings are obviously non-lazy, but _(tmpl).format(_(part)) seems fine?
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.
Isn't that already the case? I thought that when you use multiprocessing in Python, a new process gets forked, and while each new process has separate virtual memory, that virtual memory points to the same physical location until the process tries to write to it (i.e. copy-on-write)?
Sharing post-fork data is where it gets interesting.
Earlier quoted context omitted.
Also, why abandon printf-style? All languages tend to converge to printf over time, it's simply the most tried and tested model out there!
javascript, python, rust, etc. don't use printf style, but instead use the {} style.
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. That's not universally true. C# has more features than Java but is generally easier to read and the intent of the code is easier to follow. The lack of features, like properties or unsigned integers, leads to Java coders creating much more convoluted solutions. If languages wi…