If you use pandas with SQLAlchemy, you should be aware that pandas might not be fully compatible with SQLAlchemy 2.0 yet.

Some github issues:

https://github.com/pandas-dev/pandas/issues/40686

https://github.com/pandas-dev/pandas/issues/40460

I'm not actively following how compatible pandas has become, but you should absolutely test your code if you want to upgrade to 2.0.

Assuming it is ebikes that cause these fires, the scary thing is that residents may use water to put out fire without knowing what could happen.

Not just e-bikes but scooters, and I'm convinced the main driver of these fires is delivery apps.

Delivery app riders tend to have bikes with massive batteries to improve range and speed, but under-engineered electronics to cut down on cost.

I don't blame them for trying to make a living but it'd be great if the delivery apps themselves could take a more proactive stance and maybe subsidize some "known good" e-bike brands so they're not creating an army of Alibaba-specials with minimal QC ready to burst into flames.

The gif showing the backtracking is cool. I wonder if there's similar tool for python.

When I use curl, it's mostly when I need to check header or to trace requests in the network, for which I just use -vvv. Simple one-off stuff.

So I wonder how much demand there actually is for advanced features like this. When I need to make POST requests with queries and data, I would just use python because I most likely need to process the response (parse html, store json output to database, etc.).

Adding advanced features are nice, but IMO this might lead to over-engineering and it might be hard to maintain down the line.

> Adding advanced features are nice, but IMO this might lead to over-engineering and it might be hard to maintain down the line.

curl's not exactly a new project -- this is 'down the line' for it.

I personally welcome the change. I wont use it often, but when I will, I'll be quite happy that it's there. There are a number of other features I'd give up in it's stead.

> Adding advanced features are nice, but IMO this might lead to over-engineering and it might be hard to maintain down the line.

Well, one person [1] has been maintaining it since 1998. It's a good thing that HTTP doesn't change that often.

[1] https://daniel.haxx.se/

More than several times, there are data APIs that return raw text/csv, esp taking data from older systems.

Writing a scraper for those, bash & curl comes in handy w/o needing extra cruft of file writing ceremonies (ex: with open…), just pipe straight to file.

But there are people who ride illegal ebikes that go faster than 24km/h and I have never seen them getting caught

50cc scooters/bikes typically can go around 30-60mph (50-100kmph), so that comparison feels a bit unfair.

50cc is typically about 30mph max. 30-60mph is more the 90-125cc category.

Funnily, 50cc scooters/bikes are limited to 30km/h max! It's common to exceed the limit a bit.

It might depend on country, but typically it's 30 MILES per hour or 50 KILOMETERS per hour, which are roughly equivalent and match default speed limits on most European roads.

45 km/h I think. 50cc and/or 4 kW depending on type of motor.

But basically with light driver this isn't too hard enforcement.

How does that work when going downhill?

30km/h at the crest can easily turn into 60+ km/h at the bottom if it's steep.

Of course, the manufacturer knows all the drivers are responsible and follow the law exactly and thus brake to not exceed the speed limit. ;-P

It’s just the legal !important speed limit for 50cc class(“Type I bicycles with prime mover”).

This looks great, but many orgs use auto-generated documentations for client libraries (e.g. OpenAPI), which IMO doesn't give you easy-to-understand introduction/overview. And I've seen many documentation I have to decipher.

Although tools like OpenAPI has its own place when it comes to documentation, should we maintain "intuitive" end-user documentation separately? I don't think this can be automated based on the code.

> Should we maintain "intuitive" end-user documentation separately?

The answer is a resounding “yes”. Definitions are an important part of API documentation, but user guides and tutorials are equally important if you really want to empower developers. OAS really doesn’t support much additional information outside of definitions and simple descriptions, so complimentary documentation is often needed.

I own server API SDKs at Mux, and we use OpenAPI to drive our generated ones. If you use OpenAPI and generate client SDKs from it (rather than expecting end consumers to do so -- there are usually enough rough edges in the base SDK that I find it worth doing so) it's pretty easy to pack these in by editing the README templates on a per-platform basis or the like.

I always have different python versions on system level (`$ sudo apt install python3.7 python3.8 python3.9 python3.10`) and use virtualenv to manage versions for each project (`$ virtualenv env -p python3.9`), and that has served me well for years. Could someone tell me why pyenv is superior?

pyenv can compile Python versions that might not be available with "apt install" yet. And you can have multiple minor versions available (3.7.8 and 3.7.9, for instance), if you ever need it.

I don't know if it's "superior", but it helps you manage / install / uninstall / set system Python versions, as well as virtualenv features. That's it.

Thanks. IMO changing system python versions might confuse some people.

I often have to debug not-so-tech-savvy colleagues' python scripts/environments.

If we used pyenv, I could picture me telling them that they forgot to switch system python environment.

If you forget to activate the venv you cannot accidently install packages in your system python.

What DAW do you use? I tried Ardour but gave up because MIDI experience wasn't good compared to Cubase.

Not OP, but I use Bitwig. It's well worth the money.

Reaper's also worth a look if you're primarily recording, but it does have some MIDI capabilities.

Ardour does actually not have a good MIDI experience ... this will change with the upcoming 7.0 version. The MIDI experience overall doesn't have anything to do with Jack

What are some of the problems y'all have encountered with its MIDI experience? Seems to be alright for me, though I ain't doing anything particularly fancy with it.

I currently use Bitwig because it's the only Linux-native DAW that I can grasp. If Ableton released a Linux version, I'd probably switch.

Interesting you and others use Bitwig, which I've never even considered using before. Maybe I should pay broader attention.

It is quite pricey (or you can buy the cheaper 16-track version) and still missing some substantial DAW features, so it's not an obvious choice.

Indeed that does make charts look better. I do this for grid line:

ax.set_axisbelow(True) ax.grid(True, alpha=0.3)

That looks really cool. Would you possibly share the script?

It's part of the repo.

https://github.com/enter-haken/schema/blob/master/schema.sh

It's a mixture of sed, awk and sql.

Oh I did take a quick look at the repo but didn't notice it was in the SQL. Thank you!