naftaliharris

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.

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.

Please apply at https://jobs.lever.co/sentilink.

[1] https://businessinsider.com/synthetic-fraud-detection-startu...

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

[1] https://businessinsider.com/synthetic-fraud-detection-startu...

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

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

Apply here: https://angel.co/sentilink/jobs or email me (first name at sentilink.com).

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.

Do customers not want to try out the bike before buying? Especially for $5k+...?

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!

[1] https://projecteuclid.org/euclid.aos/1176345691

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.

[1] https://en.wikipedia.org/wiki/James%E2%80%93Stein_estimator [2] https://www.naftaliharris.com/blog/steinviz/

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.

[1] http://www.paloaltoonline.com/morguepdf/2017/2017_03_24.paw....

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.

[1] https://www.creditkarma.com/tax

Yes, Tauthon. (https://github.com/naftaliharris/tauthon).

It lets people with Python 2 code start to use new features from Python 3. (It's a backwards-compatible fork of Python 2.7 with features like async/await, function annotations, and keyword-only arguments backported from Python 3).

(I'm the primary author of this interpreter).

> Backporting features will be hard

It's actually pretty straightforward: I just find the relevant changes in the Python 3 history, and apply them to Python 2. Usually a handful of things have changed between 2 and 3, so I typically can't just pipe the diff to "git apply -3", but frankly backporting features is more tedious than difficult. If you're interested, for example, here's my recent implementation of the "nonlocal" keyword; you can see the commit messages reference the Python 3 commits: https://github.com/naftaliharris/placeholder/pull/60

> Why try to create an inferior python 3?

The ultimate goal is to build an interpreter that can run both Python 2 and 3 code. Unfortunately, there is some code that runs and has different behavior under Python 2 and Python 3 (e.g., 'print("a", "b")' ), so anyone who wants to write an interpreter that can run both kinds of code will need to decide what to do there. I decided to defer to Python 2 behavior in those cases, since most of my code is in Python 2 and I don't want to change it. :-)

This article misses one of the biggest value-adds of arXiv, at least in my field (Statistics): since almost everyone posts to arXiv, you can almost always find a free version of a published and potentially pay-walled paper. In the past, publishing in a peer-reviewed journal would (1) improve the paper through peer review, (2) signal the quality of the paper based on the prestige of the journal, and (3) distribute the paper. With arXiv, publishing now only does (1) and (2).

> the writing has been officially on the wall ever since 2011 so at that point you have to admit you did choose to incur tech debt and do nothing about it, so the claimed loss of productivity is on you.

When Python 3 was released, it offered Python users a trade: In exchange for a productivity loss (porting your Python 2 code), you'd get a productivity gain (new features in Python 3 and removed cruft). Some projects and companies thought this was a good trade, and have upgraded over the years, and many have not, and haven't. The interpreter I've been working on tries to improve on the terms of that deal for people who have not switched to Python 3.

> What a terrible, terrible situation. Now you'll have "python" code that will neither run on 2.7 nor run compliantly on 3.x.

That's the point, yes. Obviously any interpreter that's backwards compatible with 2.7 but includes new features from 3.x is going to let people write code that doesn't run under 2.7 or 3.x. But what does it matter if your code doesn't run under interpreters that you aren't using and don't intend to use?

> Just call it anything else

I'll change the name.

> It's also especially irresponsible and hubristic to attempt to make a language that is seemingly compatible with both Python 2 and 3, because 1) I trust that if it was possible Guido and the other developers would have made it

It is possible actually, that's kind of the point! The interpreter I've been working on passes the 2.7 unit tests (i.e. those in Lib/test/), and as well as unit tests for the new features that have been backported from Python 3.

Even if you don't believe me, it's interesting to note that, e.g., while Python 3.0 was being developed, function annotations and keyword-only arguments coexisted with tuple unpacking. I built the code and ran it myself, in fact: https://twitter.com/naftaliharris/status/784421498291310592. Tuple unpacking was actually removed later, introducing the backwards incompatibility after the new functionality had been added. Timeline:

Oct 2006, keyword-only arguments.

Dec 2006, function annotations.

Mar 2007, removing tuple unpacking.

There was also a promising backport of keyword only arguments to CPython 2.6 (!) that was never merged, (http://bugs.python.org/issue1745), due to lack of follow-through.

Author here. Imagine my surprise when I got back from a day of sightseeing (I'm on vacation in Spain) and saw that this had blown up. I had intended to "release" this project after New Years, after I'd gotten back and a week or two after 3.6 is released [1], and didn't expect this to get picked up since the project has been on Github for over a year (although inactive for much of that time) and since my blog usually doesn't get much traffic.

A lot of people here have strong opinions about the name "Python 2.8". I don't mind changing it, and intend to do so, (https://github.com/naftaliharris/python2.8/issues/47). I picked it 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!

For those of you with 2.7 codebases or projects, I'd be extremely interested in hearing about whether you were able to get this interpreter to run your code. Personally, the biggest challenges I've had so far are with dependencies that check for `sys.version_info[:2] == (2, 7)` as opposed to something like `sys.version_info[0] < 3`. But I'd be very interested in other people's experiences, particularly with larger codebases.

[1] A minor and somewhat pedantic point: The interpreter I've been working on includes PEP 515 (underscores in numeric literals), which is new in 3.6. I didn't think it was right for me to "take credit" for this new feature before it was even out in Python 3.6. Obviously, the real credit for this feature existing (in 3.6 or in any interpreter) goes to the CPython core devs, and especially Georg Brandl.

http://sebastianraschka.com/ has some great articles for machine learning in Python.

Very neat to see the how the centroids move to the equilibria. Also interesting to look at other point distributions to see what happens in more pathological cases. (For the interested, I once made a kmeans visualization http://www.naftaliharris.com/blog/visualizing-k-means-cluste..., there is one in the sibling comment to this, and many others can be found with a little googling).

I use ack! http://beyondgrep.com/

It would be nice if you could showcase some of the value of prisvo without requiring a signup.

Interesting! The approach I take to the "script fails after running for an hour" problem is to drop into a debugger on an exception. I use https://gist.github.com/naftaliharris/8284193 for this but you can also use "python -m pdb myscript.py" or "python -i myscript.py" and then "import pdb; pdb.pm()" when your script fails.

You might be right--that would definitely help people get further into the flow before the high-friction "payment" step. (If I went the "pay to view report" route I'd obviously have to be super upfront about it; wouldn't want there to be an unpleasant surprise for people at the end of the flow).

One other thing I thought about was maybe making the service free for phishing up to N people.

I'm sending the emails directly from my server with the unix "mail" utility.

Ending up in spam is actually what most concerns me about this idea, and in fact this concern was what led me to choose the "you don't pay unless someone clicks on a link" pricing--I was worried that some of the emails might eventually start ending up in spam after a few customers and wanted to make sure I wouldn't be charging people if that happened.

I'm planning to see what works once/if the phishing emails actually start ending up in spam.

Thanks, and very cool project!

> Quick question - are you concerned about trademarks (Amazon and such) being included as the phishing templates?

I'm honestly not 100% sure, but I think in the context of a phishing site using trademarks like that falls under fair use. But IANAL.

> Github has spf records setup so I would be interested to know how you manage to spoof the actual email address itself without getting flagged as spam.

I don't know much about spf records, honestly--for every site I had to try multiple "From" and "Reply-To" addresses to get the emails past gmail's spam filter. Some of them didn't even arrive in my spam folder, (apparently they just got killed on some intermediate hop). support@github.com definitely works, at least for me--you should try it yourself and see how it goes.

Hope this helps!

Thanks and thanks for the suggestion! One thought I'd had was longer/more in depth campaigns. It's good to know other people would be interested in that as well.

One thing I was concerned about was that people might not trust some random guy on the internet to properly discard those credentials.

Affirm - San Francisco, CA

Why do banks charge fees on checking accounts, an interest-free loan? Why do ACH payments like direct deposits take days to clear in an age when communication is instant? Have you ever read the fine print on a credit card?

At Affirm, we think the consumer finance industry is fundamentally broken. Banks today offer complicated and expensive financial products with a multitude of fees and gotchas buried deep in their fine print, a result of them losing touch with their customers and continuing to use inefficient and costly infrastructure built with technology from the 1970s.

We at Affirm are using modern technology to re-imagine and re-build core components of financial infrastructure to enable cheaper, friendlier and more transparent financial products that improve lives. Our first product, "Buy With Affirm", enables consumers to finance large purchases and and has been integrated into over a hundred ecommerce sites.

We are based in downtown San Francisco; founded by Max Levchin (founding CTO PayPal), Jeff Kaditz (CDO DeNA/ngmoco), and Nathan Gettings (founding CTO of Palantir); and have raised $45M from Khosla Ventures, Lightspeed Venture Partners, Nyca Partners, and others.

My team at Affirm is looking hard for data scientists, (but Affirm is also hiring software engineers, designers, PMs, and others; see the whole list at https://www.affirm.com/careers/).

RESPONSIBILITIES

- Build production fraud and credit machine learning models. Your models will decide who we lend to in real time.

- Conduct ad-hoc data analyses. Your analyses will decide what policies we adopt, where we expand our business, and who our partners will be.

REQUIREMENTS

- Deep understanding of and experience with machine learning and data analysis.

- Strong programming ability.

BONUS

- Expert-level Python ability.

- Advanced statistics knowledge.

- Experience with fraud or underwriting.

Apply at https://www.affirm.com/careers/data-scientist/ or email us at careers@affirm.com.

FULL-TIME, INTERN, VISA, LOCAL, RELOCATION, NO REMOTE

It's interesting that they chose to write their anomaly detection code in R, which is typically used in offline, post hoc analysis mode. It seems reasonable to suppose that the ability to discover an anomaly like "service X is failing" in real time is more valuable then discovering it a week later.

In order to monitor important time series with this code, they would presumably need to run it every n minutes on the entire time series, or at least the recent part of it. Seems an anomaly detection system operating on streaming data might make more sense.

Perhaps their real time anomaly detection system uses simpler logic on streaming data?

Affirm - San Francisco, CA

Affirm (affirm.com) is re-inventing consumer finance. We're starting with lending, and looking for data scientists to build the systems that decide in real time which loans we make. We are based in San Francisco; founded by Max Levchin (founding CTO PayPal), Jeff Kaditz (CDO DeNA/ngmoco), and Nathan Gettings (founding CTO of Palantir); and looking for exceptionally talented and passionate people to join us on our mission.

RESPONSIBILITIES

- Build production fraud and credit machine learning models. Your models will decide who we lend to in real time.

- Conduct ad-hoc data analyses. Your analyses will decide what policies we adopt, where we expand our business, and who our partners will be.

REQUIREMENTS

- Deep understanding of and experience with machine learning and data analysis.

- Strong programming ability.

BONUS

- Expert-level Python ability.

- Advanced statistics knowledge.

- Experience with fraud or underwriting.

Apply at https://www.affirm.com/careers/data-scientist/ or email us at careers@affirm.com. (We're also hiring software engineers, designers, PMs, and others; see the whole list at https://www.affirm.com/careers/)

FULL-TIME, INTERN, VISA, LOCAL, RELOCATION, NO REMOTE

Affirm -- San Francisco, CA

At Affirm we believe the financial industry is fundamentally broken. Not only is the core infrastructure built with technology from the 1970s, but when is the last time you hard someone say say "I trust my bank to look out for me". It doesn’t have to be this way, and it’s our mission to fix this problem. We are using technology to re-imagine and re-build core parts of financial infrastructure to enable cheaper, friendlier and more transparent financial products and services that improve lives and return the financial service industry back to its roots: value creation as opposed to value extraction.

We are based in San Francisco and are founded and backed by industry veterans, including Max Levchin, (Affirm CEO, PayPal cofounder/CTO) and Nathan Gettings, (Affirm Chief Risk Officer, Palantir cofounder/CTO). We are looking for exceptionally talented and passionate people who believe in our mission and want to be a part of shaping the future of consumer finance.

We're looking for full-stack engineers, infrastructure engineers, UX engineers, and iOS and Android engineers, in addition to some non-technical roles as well. Our backend is written in Python and lives on AWS.

Email me at naftali@affirm.com or apply at https://www.affirm.com/careers.

FULL-TIME, INTERN, VISA, LOCAL, RELOCATION, NO REMOTE