I don't use toggles for these common symbols like /\'[-+] . The trick is that you make the top row as same as a normal keyboard, move ]\ from second row to the bottom row as they seldom get typed (] got auto completion most of the time).
> Unfortunately, the performance analysis shows, that the retain and release introduce a big performance hit, with little information on why exactly so many calls are necessary.
The battle has not over yet.
RHEL 8 has Python 2.7 in their Application Streams.
So looks like Red Hat will provide security updates until Jun 2024
https://access.redhat.com/node/4079021
There was some mention somewhere that RH will support the python 2.7 appstream for RHEL 8 as long as RHEL 7.x is supported. Which coincidentally is June 2024, so, yeah.
The &something syntax to pass on a block is very old syntax to allow passing on a block that is reified as a Proc, it mirrors the syntax used to receive a block (if you don't want to use, or can't use yield, for example because you need to pass on the block to another method).
e.g.
def apply_to_all(&callback)
@all.each(&callback)
end
or
def initialize(a, b, c, &block)
@a = a
super(b, c, &block)
end
The only thing that &:symbol adds is that it defines to_proc on Symbols to create a Proc object that sends the symbol to it's first parameter, you could define it yourself if Ruby didn't already, and in fact it was first defined by users of Ruby before it became part of Ruby core.
Definition:
class Symbol
def to_proc
return Proc.new {|receiver| receiver.send(self)}
end
end
This definition allows `["1", "2", 3].map(&:to_i)` to work in Ruby 1.8.6, which otherwise doesn't support it.
I don't actually mind the syntax that much, `&` on a symbol just gives you a proc for calling `send` on the first argument. What bothers me is the limitations. If you're going to have special case syntax to avoid having a useless first argument why not go all the way?
Something like this would have made a lot more sense imo:
The cognitive burden argument is completely subjective. If you’re used to point-free programming, the first short form probably requires less cognitive burden. To me, it makes way more sense to think about “map the users list over the function that returns name” rather than “map the users list over a brand new anaonymous function that takes a user and calls the name method on it.”
Another way to look at it is that cross-pollination is a good measure of the merit of a language feature. If one language invents it another a dozen other popular languages adopt it, it's probably a good idea, and its proliferation is good for everyone.
Since we can reference other requirements with `-r req-dev.txt` inside requirements.txt .
Current requirements.txt isn't really machine-readable without firing up a full Python interpreter.
There's also a web version https://www.ptt.cc/bbs/index.html , which supports Unicode.