Is Python now becoming the new C++?
f"Diameter {(diam := 2 * r)} gives circumference {math.pi * diam:.2f}"
If this is not write-only code, I don't know what is.271–280 of 381 posts
Is Python now becoming the new C++?
f"Diameter {(diam := 2 * r)} gives circumference {math.pi * diam:.2f}"
If this is not write-only code, I don't know what is.As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. Same with the forced positional/keyword arguments and the "self-documenting" f-string expressions. Even when they have a use, it's us…
> The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. The primary one I want is if m := re.match(...): print(m.group(1)) and while s := network_service.read(): process(s) both of which are both clearer and less error-prone than their non-walrus variants. The other one that I would have found useful an hour ago is in interactive exploration with comprehensions. I freq…
Watch out with this one though. In this case it's good, but if you receive numbers from such function, it will break loop not just on None but on 0 as well. Easy to forget.
In many cases you'll need to do:
while (s:= ....) is not None:Earlier quoted context omitted.
After a quick read through, I personally find this syntax much harder to read using operator overloads than it would have been using a series of comparison functions. Tilde is a very obtuse operator and I don't know that this really buys you anything. Feels like a case of preferring cleverness over readability/usability/maintainability.
I actually had a series of comparison functions initially, but those weren't that readable. To give you an example, let's look at this statement: if exp ~ ('mask_shl', int:size, int:offset, -offset, :e): ... It is the same as writing: if type(exp) == tuple and len(exp) == 5 and exp[0]=='mask_shl' and type(exp[1])==int aand type(exp[2])==int and exp[3] == -exp[1]: size, offset, e = exp[1], exp[2], exp[4] ... If you ca…
if exp ~ ('mask_shl', int:size, int:offset, -offset, :e): ...
vs if type(exp) == tuple and len(exp) == 5 and exp[0]=='mask_shl' and type(exp[1])==int aand type(exp[2])==int and exp[3] == -exp[1]:
size, offset, e = exp[1], exp[2], exp[4]
...Earlier quoted context omitted.
Perhaps Python itself could worn you that certain constructs are deprecated and will be removed in future versions. And you could 'import something from future' to opt-in to making those warnings errors right now.
That's a pretty good idea, deprecating & warning + providing automatic conversion utilities + using 'future' to make them errors... But that won't happen :-(
As a developer who has primarily developed applications in Python for his entire professional career, I can't say I'm especially excited about any of the "headlining" features of 3.8. The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. Same with the forced positional/keyword arguments and the "self-documenting" f-string expressions. Even when they have a use, it's us…
> The "walrus operator" will occasionally be useful, but I doubt I will find many effective uses for it. The primary one I want is if m := re.match(...): print(m.group(1)) and while s := network_service.read(): process(s) both of which are both clearer and less error-prone than their non-walrus variants. The other one that I would have found useful an hour ago is in interactive exploration with comprehensions. I freq…
for s in iter(network_service.read, ''):
process(s)Earlier quoted context omitted.
Sometimes you just check for a match (e.g.of entire string) and define no groups. The problem is not in re.match but in None being a relatively poor Maybe / Optional (still ways better than C-style `null` of many other languages).
> Sometimes you just check for a match re.match vs re.search
This got missed from the release announcement, but now there's `functools.singledispatchmethod`,[1] as the class method sibling to `functools.singledispatch`.[2] This allows you to overload the implementation of a function (and now a method) based on the type of its first argument. This saves you writing code like: def foo(bar): if isinstance(bar, Quux): # Treat bar as a Quux elif isinstance(bar, Xyzzy): # Treat bar…
Nice. I missed this feature only a few weeks ago. Good to know it's landed!
It can also do dispatch on multiple arguments and on equality and has dispatch cache implemented as C extension (from my rudimentary measurements it seems that dispatch with cache hit is actually slightly faster than normal CPython method call).
man do I wish they would make multiprocessing easier
Subinterpreters are coming in 3.9, which should fill most of the same roles as multiprocessing but without the complexities and edge cases of multiple real OS processes. https://www.python.org/dev/peps/pep-0554/
Earlier quoted context omitted.
As a python programmer I would have no idea what `valid_P` is supposed to mean. Valid Pascals?
P is shaped like a question mark, though I think it was retronymed to stand for "Predicate"
Emacs Lisp, at least, can use question marks in names without batting an eyelash.
I see no reason that would not have been true for Lisps generally since their birth.