pganssle

I'm not sure I understand the question, but I can answer both interpretations:

1. Did it (the chord trainer app) help my son when he was studying music? Not as far as I can tell. He has also been taking piano lessons and sometimes it helps a little with music theory to tie it back to the chords, but I don't think there's much transfer learning going on. He seems to have a good ear, but my other son is not picking up chords nearly as quickly, and I know a bunch of other kids have bounced off this app, so my older son may just already naturally have a good ear.

2. Did it (studying music) help my son (with identifying chords)? I don't think so. He made pretty steady progress in the chords before he started piano, and after he started piano it didn't get any easier. He also mentions things like, "The chords sound different on the piano", which makes me think I need to have more varied samples (even though the book says that consistency is key and you should practice on the same piano holding the chords for the same duration every time).

I can't believe I didn't put this in the original repo, but this is where I got the piano samples from: https://theremin.music.uiowa.edu/mis.html

They have guitar samples as well, but it was a bit more complicated because with a piano you have one key per note, there's exactly one way to play C4♯ or whatever, but with a guitar the notes are overlapping, so C4♯ might be played on the B string or up on the G string, and I didn't really know how to choose samples for interpolation.

Maybe also an "identify the root of the chord" mode could be helpful to bridge from the chord sounds to single notes?

There is already a mode (it might turn on automatically for "white" chords after you reach black chords, I forget) that follows on to identifying one of the three notes, chosen at random, from the chord you just heard. That is what I'm doing with my son now and it seems to be bridging the gap, but I think a direct "which note is this" thing might work better for him.

That said, we're pretty far afield of the original Eguchi method at this point. According to the book, kids are supposed to just naturally understand the nature of notes as you improve. The book also mentions that the advanced students are doing stuff like listening to arbitrary combinations of up to 6 notes (not chords, just random combinations), but they don't really explain how that works. There's a decent amount more to do, but given that I'm not 100% convinced that it even works, I'm not sure how much it's worth it to do it.

So I built the original web app for this (it's not stolen, it's open source and I told OP they could fork it). I've been glad to see it getting more attention over the years.

One note of caution here is that with my older son we did this for a few years and it hasn't really worked as expected. He can identify all the chords perfectly every time, but when we started testing single notes, he was worse than chance at it. In fact, when I activated the secret Easter egg "red only" mode, he was worse than me at choosing between C E and G (though with practice he can now do it perfectly).

I'm working on a version where you can identify single notes instead of just chords.

Also, I gave a talk about this a few years ago and the talk is on YT if anyone is interested: https://youtu.be/l2Z6uEsx9lE

A decent chunk of my PyCon 2025 talk is also about this: https://www.youtube.com/watch?v=NNbq-o5HODY

Well, pytz actually is technically flawed at the moment because it cannot read TZif Version 2+ files, so it breaks for dates >2038 (and it would break if you tried to point it at system data generated with zic's "slim" mode), see this: https://github.com/stub42/pytz/issues/48

But you are right that pandas' use of pytz is benign and as far as I know doesn't suffer the same usability issues.

Actually, naïve times are considered aware in the system time zone. There's no good way to create a `tzinfo` object that behaves like "the system time zone" and doesn't have unfortunate consequences. See this article: https://blog.ganssle.io/articles/2022/04/naive-local-datetim...

It's not an ideal situation, but given path dependence I don't think it can be improved much from here.

To be clear, when I wrote this article, I had not yet created the `zoneinfo` module in the standard library. All the recommendations for `dateutil.tz` apply to `zoneinfo` as well, except that `zoneinfo` is also faster than `pytz`.

As mentioned in the article, this was a deliberate change in Python 3. If you read this article: https://blog.ganssle.io/articles/2022/04/naive-local-datetim... you will see why this actually makes quite a bit of sense, given the design constraints the authors were working with.

I did not realize that I never stated that in the original article. I've updated it to be a bit more explicit. Thanks!

I can't help but read all the interjections from the core developers as a strong indication of why all these sorts of things tend to fail on the vine.

I think this might be a misunderstanding of the nature of the event that these notes are generated from, unless I'm misunderstanding your objection. The point of this Q&A as I saw it was to explore the feasibility of the idea and fully flesh out the costs and benefits so that we can make informed decisions about how to proceed.

The "random interjections" are notes of caution about what trade-offs need to be made. For example, it is very easy to overlook "dark matter" code because we don't have access to it, but it's almost certainly the majority of Python code out there. It is also not a complete deal-breaker to say that some change could break unknown proprietary extensions — otherwise we'd never be able to change anything; the key is that the changes have to be worth it. A lot of that depends on details — if it's easy to update C extensions for nogil mode (even if they were designed without parallelism in mind), then making breaking changes to remove the GIL might not be so bad. If nogil mode requires that most C extensions totally overhaul their reference counting and C API usage and the changes require restructuring code rather than something that can be done with automated search and replace, that's a much bigger cost and will probably come with a long term fork of the ecosystem (which is a huge pain to deal with) and it might not be worth it.

Avoiding this sort of criticism will not make the underlying problems go away, and I think everyone involved understood that this meeting was intended to bring to light any objections that might guide the work towards ultimate resolution.

This is at worst a lateral move — you need something installed that handles your test invocation for you. It could be `make`, `tox`, `nox`, `poetry` or whatever.

For a number of reasons (detailed in the article), that thing shouldn't be `setuptools`. Even if the setuptools maintainers wanted to continue supporting this use case, setuptools is uniquely unsuited to working with this, because of the way its hooks don't fire until all its dependencies have been imported already. With `tox` you just need to make sure you have `tox` installed, and you can even specify a minimum version in the `tox.ini` file.

Additionally, tox doesn't need to be installed in your Python environment (in fact, it's an implementation detail that it's Python at all — if it were instead a Go executable, it would work the same). You just need the tool available to be invoked. This means you can install it with pipx, in its own virtual environment, through your system package manager, whatever is most convenient for you.

Sorry, I could have been more clear there, and I've updated the post. I have the "curse of knowledge" and took is as assumed that you can only do this if your particular build configuration fits in setup.cfg. For me, the fact that you have the option to use a setup.py is one of the biggest selling points of setuptools. For other build backends, it's common to have a great experience when you are on the "happy path" and then have no options when you have any of a million exceedingly rare deviations. So if I had a complicated build like you have (and I do have some mildly complicated builds where this is the case), I'd look at that bullet point and think, "Ah, that doesn't apply to this, but it's good to know for my simpler projects".

That said, it would be really nice if at least the C-extension part of this worked with the declarative format. My OSS time has been severely curtailed lately and I'm spread way too thin, so I probably won't be able to execute on this, but my long term vision for setuptools has always been that most common build configurations should be achievable using declarative config only, and everything else has setup.py as an escape hatch. This is similar to the way almost all Rust projects are configured with Cargo.toml, but in rare cases you can use build.rs to execute some Rust code as part of the build.

I think that it is true that I should have written this article or something like it years ago, but there's still a long tail of people who don't even know that invoking setup.py is bad, or that the goal is to get rid of all setup.py commands.

Probably the biggest stragglers will be build scripts, and as recently as mid-2020, the answer to "how do I build distributable artifacts without using setup.py" was still "you can do it but there's no good definitive answer": https://stackoverflow.com/q/58753970/467366

There's also been a lot of mixed messaging in this space, so I think there's a decent population of people who think that the way to stop invoking setup.py is to stop using setuptools entirely, mixing up "don't invoke setup.py" with "use a backend that doesn't have a setup.py".

But you are right to say that this has gotten a lot better over time and the word is slowly getting out.