If there's a language that does this right, all ears? But I havn't seen it -
The use case described is for a small one off script for use in CI, or a single file script you send off to a colleague over Slack. Very, very common scenario for many of us. If your script depends on
a => c
b => c
You can pin versions of those direct dependencies like "a" and "b" easy enough, but 2 years later you may not get the same version of "c", unless the authors of "a" and "b" handle their dependency constraints perfectly. In practice that's really hard and never happens.
The timestamp appraoch described above isn't perfect, but would result in the same dep graph, and results, 99% of the time..
Try Scala with an Ammonite script like https://ammonite.io/#ScalaScripts . The JVM ecosystem does dependencies right, there's no need to "pin" in the first place because dependency resolution is deterministic to start with. (Upgrading to e.g. all newer patch versions of your current dependencies is easy, but you have to make an explicit action to do so, it will never happen "magically")
That's an interesting link and an argument I hadn't seen before.
In my "real world" usage, I've found "bash strict mode" incredibly useful, especially when scripting things that others will be modifying. It just avoids all of the "somebody forgot an error check", "there's a typo in a variable name", etc., type errors. And pouring through logs to figure out what actually went wrong in CI/CD is brutal.
Looking at the examples:
- I don't generally do arithmetic in bash, that's a sign of "time to change language"
- Also generally use `if ...; then ...; fi` instead of `test ... && ...`
If you do the advanced type of scripting that somebody who writes a Bash FAQ does, I'm sure `set -e` can be annoying. But once you learn a couple simple idioms y(covered on the original "bash strict mode" page) you don't have to know much more to have fairly robust scripts. And future maintainers will thank you for it!
I do the same. Sounds like arrow is being implemented as an alternative, and you'll have to explicitly opt in via a dtype or a global setting, so numpy isn't going away.
I've been really impressed with what I can accomplish with lima-vm, beyond just "replace docker desktop". The latest pre-release supports Virtualization.framework, including virtiofs.
Last I checked (which was not that long ago), Lima was stuck using 9p because QEMU for Darwin didn’t yet support virtiofs. Has this changed? Or maybe I’m just misremembering the details…
I recall seeing my first PHP/FI page in the middle 90s. PHP was a godsend after you'd suffered with Apache's "server side includes" [0], which is largely what it was used to replace.
Python's origin was as a teaching language (originally ABC I think?), and thus the simplicity of the syntax. It was kinda cool that Python was around for so long before it took off... I had the O'Reilly Python book way back in the 90s.
Perl's influences were awk, sed, bash, C, Fortran, and Lisp.
I really like the overall design and ethos, but a new project without typehints, pydoc, and at least some tests just isn't the kind of thing I'd bring into my stack. Hope it gets a little bit of polish!
It does have some typehints... but I don't like Python types when they require importing the object only for the purpose of types. I only import objects when they're actually used in the non-type code, and I don't like to use `if typing.TYPE_CHECKING`.
Why is this a problem? When would you reference the type but not actually need the type? If you're returning the type from some method in your API, but not instantiating it there?
Yes, if you're accepting the type as a param or returning the type. It happens very frequently, and without moving those imports behind "if typing.TYPE_CHECKING", you constantly run into cyclic imports.
Why would there exist a way in Python to conditionally import types, for the purpose of preventing cyclic imports, if cyclic imports weren't a problem?
Your comment makes it seem like you haven't experienced Python types enough, or you wouldn't think it was so easy.
> Your comment makes it seem like you haven't experienced Python types enough, or you wouldn't think it was so easy.
Oh trust me I did and I constantly slap on the wrists juniors who over-complicate their solutions to the problem :)
> Why would there exist a way in Python to conditionally import types, for the purpose of preventing cyclic imports, if cyclic imports weren't a problem?
Because it's easier to understand than the solution to cyclic imports without conditional imports.
I understand the idea of moving "iteratively" etc, but this is a major thing for me when projects are mentioned as "only took a week to get this all done" yet a lot of commonly accepted best practice is left by the way side.
Tests? We don't need no stinking tests! [1] I didn't plan to open source this so quickly, if ever. I'm just happy it's working for WakaTime. The makefile has plans for pytest, but honestly my motivation for tests has waned after fixing the production issues with Celery.
well theres a cold start problem here. your bar for adoption is understandable, yet OP is probably also seeking substantive feedback on the solution and the problem space. the top hn comments now provide neither. this discourages future posts by people testing the waters. acceptable individually but on aggregate the community loses out (eg imagine if we judged segment and sentry at launch with these standards).
It's being used in production at https://wakatime.com and performing better than Celery was, but yes it's an internal project that was open sourced early stage.
I built a local test app that does have some integration tests, and then I just went all in on production. That's why I was surprised it worked so well. I was ready to lose a few nights sleep debugging it in prod, but thankfully didn't have to.
Even well managed funds can result in someone getting the shaft. My dad's pension (Delphi Salaried) was cut to 50% of what it was supposed to be after the events of '08, and it was funded to something like $0.86 on the dollar, above the national average.
The hourly workers (i.e., unionized) still got 100%, which was pretty unfair.
My gut reaction was that as a browser extension, you would have the ability to add airlines that refuse to participate in the current travel sites, e.g., Southwest? But I don't see them in the results...
Your gut reaction is not wrong. That being said, I think it's wise to pick the right time to leverage this capability. Our resources are extremely limited at the moment in comparison to one of the most aggressively litigious entities in our space.
Southwest fares integrated with other airlines is pretty much the reason why I'd install something like this. Also, getting sued might be good PR, you could probably spin that into some great news coverage. Streisand effect.
I actually gave it a try, and couldn't successfully signup due to the phone number check, even though my name is on the line. Figure I've wasted a couple hours on it in total. Unnecessary friction.
Usually the disabled get the hardware through insurance or grants - in Texas, the state provides grants for assistive communication devices out of a fund sourced from a phone bill tax. My dad's Tobii i16 came out to ~$15k. Ex-USA, I'm sure the cost of these things is ... unreasonably prohibitive.
I'm actually kinda excited to find PyGaze, we might play with it and see if I can tweak a few things to improve his experience.
The use case described is for a small one off script for use in CI, or a single file script you send off to a colleague over Slack. Very, very common scenario for many of us. If your script depends on
You can pin versions of those direct dependencies like "a" and "b" easy enough, but 2 years later you may not get the same version of "c", unless the authors of "a" and "b" handle their dependency constraints perfectly. In practice that's really hard and never happens.The timestamp appraoch described above isn't perfect, but would result in the same dep graph, and results, 99% of the time..