Original author here. I built this a few years ago, and the main motivation at the time was that I'd heard people say that adding the new features in Python3 required breaking backwards compatibility, which I didn't believe. IMO the only feature that really required breaking backwards compatibility was the str/unicode consolidation and refactoring. This project was my way of proving that we could have gotten the other features that people tend to be most excited about (async/await, function annotations, new super(), etc) without breaking existing Python2 code. I think it was successful at that as a proof of concept.
It was a fun project; I learned a lot about how the CPython implementation works and have a lot of respect for the people that built it. It was surprisingly easy to implement Tauthon based off the work the core dev team did on Python3: https://www.naftaliharris.com/blog/nonlocal/
For what it's worth, I do believe that Python3 is a better language than Python2. We use Python 3.7 at my work (SentiLink) and we've had a good experience with it. (If you're starting a new project or can migrate, I'd recommend it). But I do think that the ~10 year saga of upgrading to Python3 from Python2 wasn't necessary when the main benefit was really the unicode refactoring.
I no longer maintain Tauthon personally but there are others who are excited about the project who occasionally add new features or bugfixes.
meanwhile exceptions just sob in a corner, forgotten.
the main benefit is actually sane exceptions. unicode is nice and all (i'm a native speaker of a non-english language) but it's a storm in a teacup IME.
First off, cool project Naftali! One of the issues that ultimately became more common as Python2 became EOL is that a lot of libraries began to release only wheels for Python 3.x variants. When there's C/C++ extensions this means that even running a compatible fork wouldn't suffice.
Do you think it would have been feasible to make wheels compiled against the python 3.x C APIs also compatible with Tauthon?
I don't know what it supposed to prove. It was no secret that Unicode was what broke compatibility, the other changes were there to use that as an opportunity to fix warts that accumulated over years (like organization of system packages, print statement, division, classes etc. I don't believe Thauton fixed these things though)
It was no secret that everything else was portable, that's essentially all what python 2.7 was - backporting 3.x features to Python 2. It was a waste of resources for developers to maintain 2 forks of Python so that effort was stopped in 2015. There was 5 extra years to move application to Python 3.
5 years is frigging long time in computer terms, and your project felt still like giving f-you to the core developers for trying to improve the language. Trying to call the project Python 2.8 was very aggressive and would create a lot of confusion if Guido would accept that.
I'm glad you gave python 3 a try, I feel like the people that were against it didn't write any new application in it, and their experience was porting Python 2 code to 3. It can be very frustrating when Python 3 complains about bugs that Python 2 just ignored, but if you write a python 3 application from scratch you don't even notice the Unicode, and that was the goal.
Some of the changes I feel were a step too far though. Completely removing iter{items,values,keys} just made the migration so much more painful. I would say I spend a significant amount of time figuring out if I want to rely on six or if the array is small enough that I can live with unoptimal .items() in py2 throughout the migration. What would've been the issue of keeping .iter*() calls around, with a warning maybe? In general, there's a lot of stuff that could've been kept for backward compatibility, with a warning. It's much easier to slowly fix issues like that over time as you maintain code than to have to convert it all in one go, which put a giant barrier for people want to switch.
I feel a bit like you’re trying to rewrite history here.
When you launched it, you called it “Python 2.8”. You posted it everywhere to gain traction, and didn’t rename it until the PSF and Guido got you by the ear, so to speak. There was no mention of “everything but str” or whatever, as far as I recall.
It was an outright (and hostile) attempt to fork - something that, going by your words here, I guess you now recognise as a mistake. I guess saying “I screwed up” is hard.
Can you provide citations for your claims? The commentary in the github renaming issue from 2016(0) seems pretty jovial and has the tone of "oh, actually we should change that, oops" rather than "we WILL replace python!". The comments by guido and harris reinforce this perspective:
> gvanrossum commented on Dec 10, 2016
> Since I was asked: The project's name (and its binary name) need to
> change. They are misleading. The rest looks acceptable according to
> Python's license. This is not an endorsement (far from it).
> naftaliharris commented on Dec 10, 2016
> I don't mind renaming this project. Any other suggestions for good
> names? I personally like "Pythonesque (/usr/bin/pesque)" the best so
> far, thanks @dbohdan! :-)
>
> @VanL, not that I'm necessarily picking that, but would a name like
> that be acceptable?
When you're in a community or a space, actions that are unintentionally hostile towards that community or space, can be seen as intentionally hostile by the members, and if you only hear about it second-hand, or you spend a lot of time around the group, that belief can be reinforced through the discussions and gripes the group has about it(1).
(0): https://github.com/naftaliharris/tauthon/issues/47
(1): That's not to say there aren't bona fide intentionally hostile actions that happen, but rather that's how actions that aren't intended to be hostile can be remembered and percieved as such.
It was all very disingenuous. It was obvious to everyone, after 8 years of flames, that such a move would have been incendiary. Naftali played dumb only after he was called out on it.
I'm not saying it was entirely his fault - certain widely-heard voices in the community had been advocating for this to happen, in practice, for several months; he saw an opportunity and went for it. I just object to the rewrite of history to justify the mistakes of the past.
> It was all very disingenuous. It was obvious to everyone, after 8 years of flames, that such a move would have been incendiary. Naftali played dumb only after he was called out on it.
Have you considered that not everyone who forks something participates in the original community?
> I just object to the rewrite of history to justify the mistakes of the past.
So far there has been no evidence for the stated claim, just supposition and rumour. So as-is there's no reason for anyone here to believe that "history is being rewritten" aside from easily-mistaken word of mouth.
These days most discussions over the internet happen via the written word, so it's difficult to believe that you can't find records from IRC, Github, or Email to support your contention that it was hostile.
You're coloring the history with a lot more hostility than the reality. And the condescension is really unnecessary.
This matches the pattern of Python.org developers and python 3 aficionados being unnecessarily hostile and condescending to the concerns of Python 2 language users. You saw that in 2010; you saw it again in 2015; and you can see it in these threads today.
Can you explain the specific actions that were taken that didn't cater to, as you say, "python2 language users"? A 12 year migration timeline seems, to me, to be fairly lax.
None of the things you mentioned are particularly difficult though. In fact you're still in the realm of changes that can be trivially automated with https://python-modernize.readthedocs.io/en/latest/fixers.htm..., the three issues you describe are the print, xrange_six, and classic_division fixers.
It's certainly possible that there are parts of the migration that would be tricky, a quick skim of the file didn't give me any obvious ones, but it's also huge and hard to read, so I very well could have missed something.
Most of the truly challenging things to migrate involved some combination of extension modules, heavy metaprogramming (eval/exec), and apis which change significantly between 2 and 3 (most of which are string related, but some libraries also decided to do backwards incompatible things)
I am definitely guilty of being "hostile and condescending" to people asking the Python.org developers to waste time supporting Python 2. Please just stop. This time would be better spent working on the packaging situation rather than relitigating the last 12 years.
If people still want to work on Python 2 projects that's fine and it's their choice, but it's time to just let the rest of us go our own way.
I wouldn't call it a "hostile" fork. Imagine what motivated him to fork in the first place. He and many others were between a rock and a hard place, and a fork was a possible way out.
At the time, the author stated:
> I picked [the name "Python 2.8"] initially since when talking with friends about this project it conveyed pretty darn immediately what the project is and does. I'd be very keen to hear people's suggestions for alternate names!
This was no mistake or screw up at all. In fact, the project served his purpose for the time, and even though he's moved on, there are others who like it enough to maintain or improve it.
A fork is (or can be) a healthy, natural thing that happens.
Do you have any references that support the level of invective you are displaying? I feel you are projecting a great deal of ill will on the original author that I, personally, didn't feel or see.
As a general question, why is forking a project perceived as hostile? I always thought that forking an open source project was something that was encouraged if one's proposed contributions were not incorporated into the original project.
I think there is some demand for legacy Python 2 to be maintained, even if the maintenance is limited only to security fixes, and I think it would be good if some company paid you or someone else a full time salary to continue maintaining this Python 2 fork.
It’s a tragedy of the commons: A lot of companies making good money are still using Python 2, but none of them are willing to pay programmers to maintain an open source currently maintained Python 2 fork.
ActiveState is offering commercial support for Python 2, for those who need it. But places that are so conservative as to need it, are also precisely the ones that will want vanilla Python rather than a fork.
SentiLink | Software Engineer (backend, platform, infra, machine learning, data science) | ONSITE | San Francisco, CA | sentilink.com
SentiLink prevents synthetic fraud, an emerging fraud vector in which fraudsters open accounts using name/DOB/SSN combinations that don't correspond to real people. Our partners include top ten US banks, fintechs, and alternative lenders. We're backed by investors including Andreessen Horowitz, Max Levchin (Affirm CEO/PayPal Co-Founder), and former presidents/CEO's of Visa, Transunion, HSBC, and Citi.
We recently closed a $14M Series A [1] and are hiring software engineers to help us build our identity platform. Our tech stack uses Go (for the API part) and Python (for the ML part) on k8s and the work involves a lot of complex and sensitive data.
SentiLink | Software Engineer (backend, platform, infra, machine learning) | ONSITE | San Francisco, CA | sentilink.com
SentiLink prevents synthetic fraud, an emerging fraud vector in which fraudsters open accounts using name/DOB/SSN combinations that don't correspond to real people. Our partners include top ten US banks, fintechs, and alternative lenders. We're backed by investors including Andreessen Horowitz, Max Levchin (Affirm CEO/PayPal Co-Founder), and former presidents/CEO's of Visa, Transunion, HSBC, and Citi.
We recently closed our Series A [1] and are hiring software engineers to help us build our identity platform. Our tech stack uses Go (for the API part) and Python (for the ML part) on k8s and the work involves a lot of complex and sensitive data.
Please apply at https://angel.co/sentilink/jobs or shoot a resume/github/linkedin to me, (my first name at a domain I'm sure you can guess).
Two super interesting things about this kind of fraud which make it especially tricky to catch and deal with:
1. Unlike with ID theft, there's no consumer victim. With ID theft, eventually the victim will find out about it, (by getting a call from a collections agent or seeing the trade on their credit report). They'll then contact the lender or the bureau, and contest the validity of the loan. The end result is that the lender gets a stream of loans that are labeled as identity theft losses. Since there's no consumer victim with synthetic fraud, though, lenders don't get this stream of labeled data and have a hard time knowing which of their losses are synthetic fraud (and which are just ordinary credit losses).
2. Synthetic fraud cuts right through typical ID theft prevention systems. ID theft prevention is about checking whether the applicant is the same as the identity they're using to apply for credit. So you check if the email the applicant uses matches the identity, (e.g. don't want john.doe@gmail.com used as the email for Jane Smith), you check the phone number, you check if the applicant can complete KBA (knowledge based authentication, e.g. questions about previous addresses), you check the billing address, and so forth. But synthetic identities have their own aged phone numbers, emails, addresses, and credit histories, and so all of these verifications go through without any flags raised. Essentially the ID theft prevention system was checking whether the applicant is the same as the identity that they're using, but with synthetic fraud the applicant created the identity.
Source: my startup focuses heavily on preventing synthetic fraud for lenders, (PM me for details).
I know you're not asking for my advice, but you're pushing the dirt around here.
You're not solving the problem of ID Theft, you're just making it more likely that the criminals who are going to do it are going to use it are going to use ID's of real people.
Congrats and all for figuring it out how to do it, and for developing a market around it. But to me, encouraging banks to continue to make loans with just a web site or app seems like a really bad idea.
SentiLink | Backend, Security, and Machine Learning Engineers | San Francisco | ONSITE
SentiLink is reinventing identity, beginning with financial services in the United States. The current system is broken: SSN's are used as both a username and a password, but after repeated data breaches are also effectively semi-public. Identity-verification data isn't shared, so the same fraudsters target every company and consumers have to continually reverify themselves with different institutions. Billions of dollars are lost every year to criminals who are very rarely caught or punished. SentiLink is building the arbiter of identity to bring identity into the 21st century.
Our investors include former co-founders and C-level execs at PayPal, Palantir, Affirm, Visa, and Citibank, including Max Levchin (SciFi) and Hans Morris (Nyca Partners).
It's pretty surprising students think they can get away with this. If there's any class you'd get caught in, it'd be a CS class. In the CS classes I took in undergrad and grad school, the professors would tell everyone they would be using automated plagiarism detectors, and even explain a bit about how they worked and explicitly say they were smart enough to detect the "rename-the-variables" trick.
That said, I've got to imagine that claims that "as many as 20 percent of the students in one 2015 computer science course were flagged for possible cheating" are a misrepresentation or a misunderstanding, on the part of the journalist. I mean, sure, if you set the threshold for the plagiarism detector at a low level, you can flag 20%, 50%, or however many students you want for "possible cheating", but it's not necessarily a real thing.
A less popular but perhaps more influential phenomenon is Stein's Paradox [1]. Here's a provocative example often given to illustrate it: Say you have a baseball player, soccer player, and football player, and you wish to estimate the true mean number of home runs, goals, and touchdowns each scores per year. If you have their last ten seasons worth of data for each, then the obvious thing to do, for each player, is to estimate the true yearly mean score for each player by their average yearly score from the last ten years. (E.g., the baseball player hits an average of 20 home runs each year, so let's estimate their true mean yearly home runs by 20). Stein's Paradox says that you can actually do a lot better than this.
Even more crazy, the James-Stein Estimator which does this actually uses data about the football player and soccer player to make predictions about the baseball player, (and vice-versa). This is deeply unintuitive to most people since the players aren't related to each other at all. The phenomenon only holds with at least three players; it doesn't work for two.
(More generally, Stein's Paradox is the fact that if you have p >= 3 independent Gaussians with a known variance, you can do better in estimating their p-dimensional mean than just using their sample means).
I've spent a bunch of time trying to understand why this actually works [2]; to be honest I still don't deeply understand. But nonetheless the consensus is that the same shrinkage phenomenon is what causes improved performance for a variety of high-dimensional estimators, (lasso or ridge regression, e.g.), making the paradox very very influential.
Not sure I understand. Why should the number of home runs per year, the number of goals per year, and the number of touchdowns per year have equal variance?
You probably wouldn't expect them to. But the same kind of Stein phenomenon holds under a much broader set of conditions, including arbitrary covariance matrices and arbitrary quadratic loss, (see e.g. [1]). It's a very general phenomenon!
I'm going to go out on a limb with my intuition, and hypothesize that the underlying premise of the method zeroes in on a common characteristic of games humans tend to enjoy.
A universe of people wouldn't find these games generally interesting, if they didn't present outcomes above a certain threshold of unexpectedness. The underlying rules of each game are tuned into the equipment used, and a balance is reached, where game play is fair, but still requires players to develop skills.
Because each sport adheres to the premise of capturing interest in players and spectators, they all present the same scoring tendencies, when aggregating and generalizing.
If you change the motive of the activity (mix games with non-games), and the artifact that represents success (mix freely tallied points with rare physical tokens or discovered evidence), so that the behaviors being compared are dissimilar, the predictions will become unreliable.
For example, when comparing "victories" across lawyers, geological prospectors, and sports players you probably would not be able to make predictions about all, by lumping each area's statistics together. A gold-mining prospector probably wouldn't encounter success in the same way a trial lawyer would, and neither would help you predict or generalize a hockey game.
But, an oil driller, a diamond prospector, and a gold prospector would likely compare, based on the geological goal sought. A forensic analyst, a private detective, and a trial lawyer might compare, also, based on the human factors of investigation. And, thus, so too, with sports where freely tallied points measure a player's skill at achieving an event in game play.
I don't understand. If the average of the last 10 seasons is 20 home runs, what would be a better predicted value? You are a bit short in explaining here?
Your site, and the Wiki link, is very math formular heavy. Is there an explanation for someone who forgot all his statistic courses and greek letter thingys?
It's still math heavy, but there is some explanation. It's hard to explain without the math, since the math if fairly integral to it, that's why it's such an amazing discovery. My understanding is that it's saying that the variables are independent, but the measurement is not. So in the case of the athletes, it's not that home runs predicts touchdowns or goals, but that by using a Stein Estimation we would get a more accurate measure of all three in aggregate. The example used in the article is less interesting, but probably better for understanding:
For example, if i=1,...3 represents the financial cost of claims a multi-national insurance company will incur in the next year in three different countries, the company may be less concerned with estimating the values of the individual means accurately and more concerned with getting an accurate overall estimate.
then it pays off to bias each estimate – Ph, Pg, Pt – slightly towards zero. If any of the observed values is larger than the true value, we do improve the estimation by using a correction coefficient slightly under 1. If the observation happens to be smaller than the true value, we do make a mistake. But we make a smaller mistake when the observed value was small because it was small, than what we improve when it was large. A set of 3 independent variables is already large enough that this gamble pays off in average (in the combined total error of the 3 estimates).
Here's my intuition. Let's say you have 1000 coin flippers. They flip a coin 10 times, and none of them has any special powers, and the coin is fair. Some of them will get an equal number of heads as tails, but there's a good chance you'll get tsome who get 9 or 10 heads, and also some who get 9 or 10 tails. As the probability to get 10 heads in a row is 1/1024, if you see one or two guys how get only heads, or only tails, you will attribute that to the natural variability of the outcomes.
Now imagine that these are not coin flippers, but some guys who have some skills to do something, but the outcome has a large variability nonetheless. For example running backs in the NFL league. There are running backs (RB) who average 2 years per carry (ypc), and others who average 5. 5 ypc is stellar by the way, 4 is very good, 3 is decent, and 1 or 2 not so much. But obviously, RBs get a different yardage for each carry. Now, let's say you follow the first 4 games of the season and get the average ypc for each RB. You would like to predict for each RB the average ypc for the rest of the year. The classical statistical estimation is that the current average is the best estimator for the future average, but from the extreme example with the coin flippers above, we know that this is not quite the case. Using a bayesian estimation, we get that a better estimator is if we move the current average towards the overall mean. This is called a shrinkage or James-Stein estimator. In the case of the coin flippers, you move the average all the way to 1/2, and that estimator is correct. In the case of the running backs, you don't shrink that much, and it's a cute exercise in math to see how much you shrink if you assume some distributions around the overall ypc for RBs in the league and around the ypc of an RB given his average ypc.
If you want some further intuition, think of the Sports Illustrated curse. It was observed that NFL players who make it to the cover of the SI magazine are generally "cursed", i.e. they don't do as well after as they did before. One amusing case is the (former) New England Patriot Jonas Gray, who made the cover of SI after a phenomenal game with the Indianapolis Colts in 2014 (201 rushing yards, 4 touchdowns), but then he showed up late to work and was promptly benched for the rest of the season. Generally though, players don't do anything stupid like that, but simply "regress to the mean". That regression to the mean is what explains the shrinkage estimator, and the Stein paradox.
This is not why it works. The James-Stein estimator applies in the case of independently distributed Normal variables with equal variance, so the individually optimal estimators for each parameter have the same MSE.
I think it is impossible James-Stein estimator of the whole sample can outperform all of the three MLE for each particular. Not that I would know of a way to generate a particular from a joint estimator.
I think I may have misinterpreted your original comment. It's true, as you say, that in the Stein estimator some individual MSEs get worse to yield a lower overall MSE. I was focusing on your example and assuming you meant this was only possible because some individual MSEs were larger than others to begin with (under the individually optimal estimator).
Yeah, reading through the Wikipedia, it looks like this reduces the total error of the combined estimator, but the error compared to an estimator of any one single parameter could be worse. So you can combine whatever crazy parameters you want, but it's only really relevant when you have things that are associated with each other somehow, and you want to reduce the total error of estimating all of them.
One thing this article and the comments haven't discussed yet is how much the viability of local newspapers depends on the local real estate market. Take a look at your local newspaper if you have one, and I bet it's chock full of real estate ads. (Where I live, the Palo Alto Daily Post certainly is, as is the competing Weekly; example here: [1]). And it makes sense: the most relevant ads for a local population are matters of local interest, and for expensive houses, the ROI for ad-spend can easily make sense.
So I expect that a big factor in whether quality local newspapers can survive is the strength of the local housing market, (measured through e.g. median house price and yearly volume). As a practical matter, this means that only in relatively affluent places is local news financially feasible, (although the housing market isn't the only reason why that's the case). It also means that more people searching for property online may present a challenge for local news.
I'm surprised the article and comments haven't mentioned CreditKarma's tax solution yet, which is (actually) free. [1] Presumably their strategy is to take the users and data they get from offering free tax filing and use them to advertise lending products. I think that's a sustainable and politically feasible way to get free tax filing, actually; I expect that in ~5 years Credit Karma will have eaten a big part of TurboTax and H&R Block's lunch.
I have not used CreditKarma's tax product, but I've heard folks say that it calculates some things incorrectly. I think that's understandable for a brand new product, but I'd be cautious about using it this year if you don't (1) have a very simple return, (2) check their work against the IRS forms/instructions and/or (3) check against another product.
(For those who don't want to give TurboTax or H&R money, I've been quite pleased with FreeTaxUSA, which is like $12 for federal and state. It's a bit less user friendly, but plenty good enough if you have some understanding of taxes, and there are way fewer upsells and overpriced crap.)
I haven't used CreditKarma's tax product either so I can't speak to its accuracy, but from my understanding they didn't build their own product, they acquired a company called AFJC which has been in the online tax space for a while.
Credit Karma missed some things in my NJ state return that would have cost me a couple hundred dollars. There didn't appear to be any way for me to manually include a correction, so I ended up filing with TurboTax (free version).
This wasn't even a particularly esoteric exemption, I expect it would have come up with anyone who worked for two different companies in the same year. Aside from that, I'm a very standard case.
So does TurboTax. Every time I've used that product, the IRS actually sent me a letter back saying "you calculated your taxes wrong, here's some extra money we owe you."
Never had that problem when using TaxAct, and I usually got a bigger refund too.
> I have not used CreditKarma's tax product, but I've heard folks say that it calculates some things incorrectly.
Can anyone else attest to this? I am going to start doing my taxes soon (for the first time in my life) and CreditKarma seems like a good solution for me.
>> You could enter your data on both sites, and if they match, file [... with the product that did the math correctly]
Square quotes mine. This should be standard practice for all tax filers using an online tool or downloadable application. In most cases you, as the taxed citizen, will be held liable for any mistakes on your return. Very few situations will find the tax software provider being legally at fault for an incorrect calculation. Protect your own ass(ets) by verifying your input with separate providers. If there any discrepancies, figure out why and file with the correct result. Do not try to "get away with" filing with the provider that is most in your favor without understanding the reason; from the point of view of your government, you might be filing a fraudulent tax return. Willful negligence of tax law is not a valid excuse in their eyes.
I did my tax return with CreditKarma and TaxAct. They came out almost identical. I filed with CreditKarma because it was free. They basically worked the same. It only took me about 10 extra minutes.
It also saved me about 1k since I had done my property taxes wrong. All in all I would say that CreditKarma was worth doing and I would use them again as long as they are free.
Side Note: I have used TurboTax and TaxAct in the past.
I tried to use their product but fell into a fringe case where I could claim my spouse as an exemption. It's literally one box and a calculation on a tax form, but their support told me I was basically SOL.
It's a nice product from a UX/UI standpoint (so usability issues to solve still), and I look forward to trying it again next year.
I used their software this year as some market research. It calculated the same return as turbo tax. I will say that the returns we used were pretty simple. While not the solution for everyone I was impressed with the usability of the software.
Edit: the state returns were for Illinois if that makes a difference.
TurboTax found several thousand dollars for me in a fairly complicated tax situation that I was completely not expecting and would never have realized on my own. Even some CPAs I've talked to have said "oh, really?" They've bought some tremendous goodwill from me with that. I'm probably sticking with them forever.
The idea is to make it easier for the average person. Those involved with subchapter S corporations are probably not amateurs and are not the target audience.
Taxes are easy for the average person. A basic 1040-A, and certainly 1040-EZ (these two cover most taxpayers), are not difficult to do on paper if you can read and have a little patience.
I'm not defending Intuit here, by the way. But most people don't need what they are selling.
True, you need the full 1040 return for that, but most people don't have enough deductions to itemize -- that was my point. The average tax return is a 1040A or 1040EZ with the standard deduction. Those are easy.
I wasn't arguing against that. Rather against the conceit that my tax situation must be the result of people conspiring to keep things complicated, when the big thing (that got me thousands of dollars) was probably something that cannot really be simplified much further. Yet TT found it for me when lots of CPAs just didn't understand it.
I have a moderately complicated tax situation. Own property. Some investments. Occasional AMT hit for options. TurboTax handles all of this well. I am happy to pay $100 where before I could easily spend ten times as much on a CPA. That said, they really should allow auto-file for people with simple returns.
You got me, developer2. I've been commenting with my real name on HN for 5 years just waiting for this moment, to get the $35 that Intuit will mail me for my comment.
I had issues with CreditKarma. The problem I faced was most likely an issue specific to me and my state. Having said that, their lack of response is a major put off. It's time like these when you need a response in a reasonable amount of time. (As a matter of fact, they are yet to respond - weeks after I figured I'll just file directly)
For others in CA, FTB's free tax filing tool works just fine.
It was a fun project; I learned a lot about how the CPython implementation works and have a lot of respect for the people that built it. It was surprisingly easy to implement Tauthon based off the work the core dev team did on Python3: https://www.naftaliharris.com/blog/nonlocal/
For what it's worth, I do believe that Python3 is a better language than Python2. We use Python 3.7 at my work (SentiLink) and we've had a good experience with it. (If you're starting a new project or can migrate, I'd recommend it). But I do think that the ~10 year saga of upgrading to Python3 from Python2 wasn't necessary when the main benefit was really the unicode refactoring.
I no longer maintain Tauthon personally but there are others who are excited about the project who occasionally add new features or bugfixes.