mhashemi

Designed for simplicity, but there's a blog post with more info here: http://blog.hatnote.com/post/135182048397/announcing-the-hat...

PayPal, Inc. | San Jose | Full Time | ONSITE

You already know PayPal, the online payments industry leader. But did you know that the cryptographic core of PayPal is now powered by Python? I'm looking for a staff software engineer with 5+ years of experience, excited by high-performance and high-scalability, interested in deep-diving security and systems programming (as opposed to the full-stack trend).

Full details are here: https://www.python.org/jobs/734/ I'm the engineer doing the hiring, you can get at me directly: mahmoud at paypal dot com

PayPal, Inc. | San Jose | Full Time | ONSITE

You already know PayPal, the online payments industry leader. But did you know that the cryptographic core of PayPal is now powered by Python? I'm looking for a staff software engineer with 5+ years of experience, excited by high-performance and high-scalability, interested in deep-diving security and systems programming (as opposed to the full-stack trend).

Full details are here: https://www.python.org/jobs/734/ I'm the engineer doing the hiring, you can get at me directly: mahmoud at paypal dot com

Hmm, the way the risk aversity in the payments climate is going, my instinct would be to look for the smallest/youngest company with the least to lose? It's a tough line to walk. Balanced is out, and if Stripe's not having it, maybe something like bluepay/bluesnap?

Note that Boltons also supports Python 3, while retaining individual module independence. Happy bolting and cooooool-RRunnings!

Python 3 support has been added as of Boltons 0.6.

BSD, go nuts!

boltons has an all-purpose cache decorator, which gives you an arrangement with a lot more in terms of flexibility and transparency: https://boltons.readthedocs.org/en/latest/cacheutils.html#au...

Please do! Quality is not uniform throughout the library, and while mro_items covered my use cases, I fully anticipate others might have more comprehensive approaches.

That's right! Boltons are meant to replace those one liners, unless you really really think downstream customers are going to be impressed with code golf birdies. ;)

Hahaha, true! Get good look, that'll be gone tonight.

One returns a list of lists, the other an iterator of lists.

split_iter() docs say, "split_iter() yields lists of non-separator values," whereas split() docs say, "Returns a list of lists." Still, I'll look at clarifying it. ;)

They're around. Doctests cover most of the library, many modules have main()s that take care of some more complex unit tests, then the applications that use the utilities cover a lot of regression cases. Tests are kept as close to the code as possible to keep each module independent and self-explanatory, as explained here: https://boltons.readthedocs.org/en/latest/architecture.html

Python 3 support is pretty trivial for all the ones that come to mind. I'll look into it tonight.

Hahaha, so glad someone spotted that. :)

gevent has lots of benefits outside monkeypatching! That said, historically we mostly chose gevent as it seemed like the better interface to greenlet, which we really liked. For the most part, we were (and in many cases still are) trying to cater to a Python community of beginners. Greenlet-based approaches seemed easier to explain than other options, and sure enough we rarely hear complaints about development complexity, etc.

they're so close to alphabetical; this is killing me

I realize this is a day late and thus ancient history in HN time, but I figure a reply couldn't hurt. You're absolutely right that it would be unwise for the typical Python team to fully adopt the stack, especially this early in the release.

In fact the earliness of SuPPort's release serves to illustrate that the primary goal: demonstrating many best practices for building servers and clients, in any language or stack. As far as gevent goes, well, that's mostly an ecosystem-dependent turn of fate that continues to serve us well. A data point gladly share, but not the core message per se. :)

That's a pretty coarse description of the Python concurrency landscape. "things are moving away"?

For one, there was never really official Python backing for gevent and other coroutine-oriented programming models. Remember asyncore? From our standpoint, Python 2.7 continues to be the industry standard, and we'll continue to target it for the foreseeable future. Should some major internal or open-source use case come along and make it advantageous for us to target Python 3, we would approach it like any other feature request. Python 2 will not be vanishing from beneath your feet anytime soon. ;)

I figured 2500 words was quite enough for an introductory post. It definitely has happened, multiple times, but the rather mundane specifics will have to wait til a future post :)

Unfortunately, unequivocally, yes, there is so much misinformation. I definitely would not have spent so much time on citations, otherwise ;)

(N.B. for returning visitors: The sooner you force-refresh, the sooner freegeoip.net rises again.)

Backstory here: freegeoip.net has an hourly per-IP limit, so we distributed the load by doing the geolocation from client browsers. This borked freegeoip after many hours of Twitter/Ars Technica'ing.

It was a good thing Github got its storage servers back up; we're now running a local clone of freegeoip, as freegeoip.net smolders.

To freegeoip.net! May it rise again soon.