Proof-reading again
Bradlee Speice
parent
90c2fc9d8f
commit
df948e4f55
|
|
@ -90,14 +90,13 @@ Finally, **I really miss list comprehensions and dictionary comprehensions.**
|
|||
As a quick comparison, see
|
||||
[this dateutil code](https://github.com/dateutil/dateutil/blob/16561fc99361979e88cccbd135393b06b1af7e90/dateutil/parser/_parser.py#L476)
|
||||
and [the implementation in Rust](https://github.com/bspeice/dtparse/blob/7d565d3a78876dbebd9711c9720364fe9eba7915/src/lib.rs#L619-L629).
|
||||
I probably wrote it wrong, and I'm sorry. Ultimately, I hope that these comprehensions can be added through macros,
|
||||
but I have a feeling that they'd actually need to be syntax extensions. Either way, they're expressive, save typing,
|
||||
and are super-readable. Let's get more of that.
|
||||
I probably wrote it wrong, and I'm sorry. Ultimately though, I hope that these comprehensions can be added through macros or syntax extensions.
|
||||
Either way, they're expressive, save typing, and are super-readable. Let's get more of that.
|
||||
|
||||
# Using a young language
|
||||
|
||||
Now, Rust is exciting and new, which means that there's opportunity to make a substantive impact.
|
||||
On more than one occasion I've had issues navigating the Rust ecosystem though.
|
||||
On more than one occasion though, I've had issues navigating the Rust ecosystem.
|
||||
|
||||
What I'll call the "canonical library" is still being built. In Python, if you need datetime parsing,
|
||||
you use `dateutil`. If you want `decimal` types, it's already in the
|
||||
|
|
@ -113,7 +112,7 @@ in a comment:
|
|||
In practice, this means that there are at least [4](https://crates.io/crates/bigdecimal)
|
||||
[different](https://crates.io/crates/rust_decimal) [implementations](https://crates.io/crates/decimal)
|
||||
[available](https://crates.io/crates/decimate). And that's a lot of decisions to worry about
|
||||
when all I'm thinking about is "why can't [calendar reform](https://en.wikipedia.org/wiki/Calendar_reform) be a thing"
|
||||
when all I'm thinking is "why can't [calendar reform](https://en.wikipedia.org/wiki/Calendar_reform) be a thing"
|
||||
and I'm forced to dig through a [couple](https://github.com/rust-lang/rust/issues/8937#issuecomment-31661916)
|
||||
[different](https://github.com/rust-lang/rfcs/issues/334) [threads](https://github.com/rust-num/num/issues/8)
|
||||
to figure out if the library I'm look at is dead or just stable.
|
||||
|
|
@ -128,17 +127,17 @@ that up to date should be a no-brainer.
|
|||
## Trial Maintenance Policy
|
||||
|
||||
Specifically given "maintenance" being an [oft-discussed](https://www.reddit.com/r/rust/comments/48540g/thoughts_on_initiators_vs_maintainers/)
|
||||
issue, I'm going to try out the following policy to keep things moving on [dtparse]:
|
||||
issue, I'm going to try out the following policy to keep things moving on `dtparse`:
|
||||
|
||||
1. Issues/PRs needing *maintainer* feedback will be updated at least weekly. I want to make sure nobody's blocking on me.
|
||||
|
||||
2. To keep issues/PRs needing *contributor* feedback, I'm going to (kindly) ask the contributor to check in after two weeks,
|
||||
2. To keep issues/PRs needing *contributor* feedback moving, I'm going to (kindly) ask the contributor to check in after two weeks,
|
||||
and close the issue without resolution if I hear nothing back after a month.
|
||||
|
||||
The second point I think has the potential to be a bit controversial, so I'm happy to receive feedback on that.
|
||||
And if a contributor responds with "hey, still working on it, had a kid and I'm running on 30 seconds of sleep a night,"
|
||||
then first congratulations on sustaining human life, and second I don't mind keeping those going indefinitely.
|
||||
I just want to try and balance keeping things moving with giving people the necessary time.
|
||||
I just want to try and balance keeping things moving with giving people the necessary time they need.
|
||||
|
||||
I should also note that I'm still getting some best practices in place - CONTRIBUTING and CONTRIBUTORS files
|
||||
need to be added, as well as issue/PR templates. In progress. None of us are perfect.
|
||||
|
|
@ -148,13 +147,13 @@ need to be added, as well as issue/PR templates. In progress. None of us are per
|
|||
So if I've now built a `dateutil`-compatible parser, we're done, right? Of course not! That's not
|
||||
nearly ambitious enough.
|
||||
|
||||
Ultimately, I'd love to have a library that's capable of parsing essentially everything the Linux `date`
|
||||
Ultimately, I'd love to have a library that's capable of parsing everything the Linux `date`
|
||||
command can do (and not `date` on OSX, because seriously, BSD coreutils are the worst). I know Rust has a
|
||||
coreutils rewrite going on, and `dtparse` would be potentially an interesting candidate since it
|
||||
coreutils rewrite going on, and `dtparse` would potentially be an interesting candidate since it
|
||||
doesn't bring in a lot of extra dependencies. [`humantime`](https://crates.io/crates/humantime)
|
||||
could help pick up some of the (current) slack in dtparse, so maybe we can share and care with each other?
|
||||
|
||||
All in all, I'm mostly hoping that nobody's already done this and I've spent a bit over a month
|
||||
on redundant code. So if it exists, tell me. I need to know, but be nice about it because I'm going to take it hard.
|
||||
on redundant code. So if it exists, tell me. I need to know, but be nice about it, because I'm going to take it hard.
|
||||
|
||||
And in the mean time, I'm looking forward to building more. Onwards.
|
||||
|
|
|
|||
Loading…
Reference in New Issue