mirror-github-bspeice/speice.io
1
0
Fork 0
mirror of https://github.com/bspeice/speice.io synced 2024-11-05 01:28:09 -05:00
Code Issues Releases Wiki Activity

Proof-reading again

Browse Source
This commit is contained in:
Bradlee Speice 2018-06-19 23:02:09 -04:00
parent 90c2fc9d8f
commit df948e4f55
1 changed files with 10 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
_posts/2018-06-19-dateutil-parser-to-rust.md
View File

@ -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.