460 karma · joined January 22, 2019
I'm a core developer of RustPython (https://github.com/RustPython/RustPython).
https://github.com/coolreader18
email: coolreader18 AT gmail DOT com
[ my public key: https://keybase.io/coolreader18; my proof: https://keybase.io/coolreader18/sigs/Su2GDvjtDUUEwvoh46jH6urxEk39D7-LCSgTRN5v56s ]
I don't really get where you're coming from here, especially with regards to this issue -- it seems like almost everyone, including Rust core team members, agree that `impl Iterator for Range` was an API design mistake, that came out of (IIRC) Iterator existing prior to IntoIterator in the pre-1.0 days. This seems to me to just be an unfixable design flaw due to backwards-compatibility rules, not something that really speaks to the design of the language as a whole.
Anyway, usually I just copy/paste a piece of code like below to use the OLC alphabet and randomly generate an id, and you could just copy the literal to use as a radix alphabet as well.
"".join(random.choices("23456789CFGHJMPQRVWX", k=5))
# check against id in dict
if userinput.toupper() in idmapping: ...
[0]: https://github.com/google/open-location-code/blob/master/js/...[1]: https://github.com/google/open-location-code/blob/master/doc..., under "Easy to use"
echo $foo
# is parsed as
echo($foo)
[..] echo(1, 2) # pass 1 and 2 to echo
echo (1, 2) # pass the tuple (1, 2) to echo
[..] proc optarg(x: int, y: int = 0): int = x + y
proc singlearg(x: int): int = 20*x
echo optarg 1, " ", singlearg 2 # prints "1 40"
let fail = optarg 1, optarg 8 # Wrong. Too many arguments for a command call
let x = optarg(1, optarg 8) # traditional procedure call with 2 arguments
let y = 1.optarg optarg 8 # same thing as above, w/o the parenthesis
assert x == y
[0]: https://nim-lang.org/docs/manual.html#syntax-precedence[1]: https://nim-lang.org/docs/manual.html#procedures-command-inv...
I'd also argue that this is one of the most ethical ways to pay developers fairly for their work, even if the author wasn't able to make that much money from it. The product the developer creates is FOSS, available to everyone after some time, and they still get paid for it (bonus; they're paid by the open source community for their work, rather than from one person/corporation that dictates their salary).
let v = match map.entry(key) {
Entry::Occupied(o) => {
o.get_mut() += 1;
o.into_mut()
}
Entry::Vacant(v) => {
update_vacant_count(v.key());
v.insert(0)
}
};
I view sum types as enabling the exact same exactness as you describe in your last line; especially since you can easily switch/match based on a specific subtype if you realize you need that, without adding another method to the base class and copying into the x subclasses that you have for implementing the different behavior.[0]: https://doc.rust-lang.org/std/collections/hash_map/enum.Entr...
let mut output: Vec<_> =
foo.stuff.into_iter()
.flatten()
.chain(bar.stuff)
.collect();
I might make it slightly more clear what the intent is by doing this: let mut output: Vec<_> =
Iterator::chain(foo.stuff.into_iter().flatten(), bar.stuff)
.collect();
But still basically the same.Very interesting article though!
I don't think so, I got "Johanna Nagata", and Nagata is apparently a Japanese surname.
func(
lambda: otherfunc(
1, 2, 3, 4
)
)
And you don't need statements, given that with haskell semantics there are no statements.